lua-language-server
lua-language-server copied to clipboard
Add support for overriding functions
The language server currently doesn't automatically infer types when overriding functions.
Example of the desired behavior:
---@class
FooClass = {
---@return FooClass
new = function()
-- create an instance of FooClass
end
---@param foo number
---@param bar string
foo_callback = function(self, foo, bar) end
}
test = FooClass.new()
-- automatically infer types from FooClass:foo_callback
function test:foo_callback(foo, bar)
-- foo is of type number
-- bar is of type string
end
There are also other issues requesting this or even reporting it as a bug: #1779 #1757 #1794
Worth noting that the type inference here is half-functional, as described here: https://github.com/LuaLS/lua-language-server/discussions/1801 Hovering over the function will show the correct types, but they will not work within the function itself.
#477
Suggestion: Add this by default to every configuration file
{
"Lua.diagnostics.disable": [
"duplicate-set-field"
]
}
Am I kidding? idk. I've been sitting on this for a couple of weeks as I accumulate many dozens of lines that say
---@diagnostic disable-next-line: duplicate-set-field
The more of those I have, the more wrong it feels. All of my work arounds feel worse. Sometimes the type of a field/member/whatever is a function, maybe with a specific signature. It's not sacred. It's a variable. Maybe just a value in a table.
I have 15 tabs open to pages discussing the issue. I've been reading them and browsing the LuaLS repos for hours now. The most frustrating of which is this one: https://github.com/LuaLS/lua-language-server/discussions/1801#discussioncomment-4579158
Maybe ---@override
would be great.
I'm getting trauma flashbacks to luau's evolving type system with this issue. Getting the best of a flexible language like lua along with some of the comforts of a strongly typed language is hard. There were a lot of people looking at that and there was a lot of iteration. It's understandably very hard to get right.
There are languages and environments I would insist on having any callbacks run through a subscribe function. I think (100% opinion based) that a lot of places where lua is used and can benefit from LuaLS type inference and annotation, it also benefits from avoiding a temptation to dive into OOP and polymorphism and instead just embrace more functional styles, data oriented approaches, maybe interfaces with annotation.
I don't know that an ---@override
annotation is going to get it right if someone gets around to taking a crack at it after all these years.
I think as it's been the last few years, "duplicate set field" may be doing more harm than good and is better off disabled. Judging by the discourse, people are spending a lot of hours trying to work around it, changing the format of their code to try to appease the warnings, and I doubt anywhere near that amount of time has been saved by the warning working as intended.