-
-
Notifications
You must be signed in to change notification settings - Fork 351
Add a shortcut annotation for adding a nil,string
return type to functions (@error
)
#3156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
In LuaLS (or emmylua_ls) that overload doesn't mean anything since it is indistinguishable from the regular signature. It should just be: --- @return table? result
--- @return string? err
local function doSomething() end LDoc was only every used for documentation, so the signatures never had to make sense from a type system POV. |
Then what about this output from VSCode with LuaLS / IDEA with EmmyLua2? My example is typed in both LS implementations as two separate signatures:
so it gives static analysis a chance to choose one of these two types when typing results. Yours results in a single ambiguous result:
According to this |
In practice, regardless of how you specify it, They can only be distinguished if each prototype has different arguments, then the tool can choose one. |
I think you are asking for tuple return type, which has been feature requested in multiple duplicated (?) issues/discussions:
Maintainers confirmed the planned syntax for this feature (but not yet implemented of course): #3086 (comment) ---@return =(true, some_type)
---@return =(false, string) Maybe we can see it in |
Returning of errors from Lua functions is often done by returning nil + error message (
nil,string
):but this syntax can get complex when function takes parameters, or has other overloads. An old solution from LDoc was to use a
@error
annotation - I propose to add something similar to LuaLS.The text was updated successfully, but these errors were encountered: