Assigning to class variable shadows inherited field

[SylviBlossom]

---@class A
---@field optional_num number|nil # Optional number
local a = {}

function a:set()
	self.optional_num = 1
end


--- @class B : A
local b = {}

function b:set()
	self.optional_num = 2
end


---@param v number # Non-nullable number
local function test_type(v) end


test_type(a.optional_num) -- Warning (expected behaviour, explicitly nullable)
test_type(b.optional_num) -- No warning (unexpected, should be the same as A)

Despite B extending A and assigning a matching value to the field, the field no longer has the type or comment annotation from A after any code sets it on B.

Additionally, code completion seems to behave strangely in this context:

[xuhuanzy]

The diagnosis is currently an expected behavior because we cannot determine if you truly need to fully inherit from the parent class.

Completion has been fixed.

[taminomara]

The diagnosis is currently an expected behavior because we cannot determine if you truly need to fully inherit from the parent class.

TBH it's safe to assume that we always want to be compatible with the base class, otherwise the code would break Liskov substitution principle, which is important for being able to upcast B to A.

[xuhuanzy]

TBH it's safe to assume that we always want to be compatible with the base class, otherwise the code would break Liskov substitution principle, which is important for being able to upcast B to A.

Everything is subject to practical definition; we're just trying to make Lua behave like it has static types, rather than Lua being inherently statically typed. However, there's a compromise: we could search upwards for the first @field definition and check if it's compatible with the first type we found. If it is, we'd use @field, but this might lead to poor performance

[taminomara]

Everything is subject to practical definition; we're just trying to make Lua behave like it has static types, rather than Lua being inherently statically typed.

That's why we have diagnostics.disable 😉

However, there's a compromise: we could search upwards for the first https://github.com/field definition and check if it's compatible with the first type we found. If it is, we'd use https://github.com/field, but this might lead to poor performance

Yes, but this particular behavior could hide unintentional bugs. If the user wants to override something in a non-compatible way, they can do so explicitly by providing a @field or a type annotation.

For example, this is what python does. If you specify a type of something in a base class, it will check that all sub-classes adhere to this specification, unless a sub class explicitly provides another annotation.

In fact, I was about to create an issue for checking for these inconsistencies.

[xuhuanzy]

@CppCXY @lewis6991 @clason Opinion?

[lewis6991]

I would expect the case with B to warn. What's the point of inheriting classes if it doesn't inherit fields?

What I would like is something like:

---@class A
---@field a integer
---@field b integer

---@class B : A
---@field a nil remove field
---@field b string change type

Though I'm not sure if this would have any undesirable consequences.

At the very least B should inherit a and b from A. Otherwise what does : A really mean?