lua-language-server
lua-language-server copied to clipboard
Disallow ? on values
How are you using the lua-language-server?
Visual Studio Code Extension (sumneko.lua)
Which OS are you using?
Windows
What is the issue affecting?
Type Checking
Expected Behaviour
? is not a type, and should only be used when marking fields as optional. If nil is explicitly allowed as a value, | nil should be used. This is in line with TypeScript.
Actual Behaviour
? does not add | nil to the value type, and the second option should be disallowed.
Reproduction steps
---@class Foo
---@field foo? string
---@field bar string?
---@field baz string | nil
local test = {};
function Foo()
return test.foo, test.bar, test.baz
end;
Additional Notes
No response
Log File
No response
?is not a type, and should only be used when marking fields as optional
No, in luals ? is also shorthand for marking the type as |nil. They (should) have the same effect, and the following is valid:
---@return table?
local function test()
end
local t = test() -- table?
print(t.a) -- warning: need check nil
But I agree that in your example, it is a bug. When you do hover preview over test.foo and test.bar on the return line, they actually get inferred correctly as string?. But the overall inferred function signature incorrectly treat them as string 🤔
I feel like there should not be three ways to do essentially the same thing. ? on types are disallowed in TypeScript, and I think LuaLS should try to match the behavior wherever it can. ? should have one specific function and that should be making properties optional.
I feel like there should not be three ways to do essentially the same thing
I agree with you personally, and this has been discussed previously in: https://github.com/LuaLS/lua-language-server/issues/2070#issuecomment-1510456403, https://github.com/LuaLS/lua-language-server/issues/2029#issuecomment-1484642935.
But as discussed in those issues, any change in the behavior of the current annotation syntax will be a breaking change. So this may not be implemented in anytime soon ☹️ given that implementing this gives no extra function to luals itself. As a user of luals, we might just stick to our own practices in our own projects to keep the consistency.
And this issue seems like a duplicate one now.
Also, Lua is not Typescript, and trying to pretend it is will only lead to more confusion down the line. (In particular, Lua itself does not distinguish between optional and explicit nil arguments.)
Also, Lua is not Typescript, and trying to pretend it is will only lead to more confusion down the line. (In particular, Lua itself does not distinguish between optional and explicit
nilarguments.)
Lua do actually distinguish between nil and optional in function calls
Example:
table.insert(t, nil) -- Valid
table.insert(t) -- Error, "wrong number of arguments"
Furthermore you can detect an explicit nil on varargs (...) via select('#', ...), so it is possible for it to have a semantic difference.