Suggestions for improving our constructors?

[ipsquiggle]

Hello, we are using a class system which requires passing in the constructor as a lambda. This plays quite poorly with LuaLS as far as I can tell. I've made it work, sort of sometimes, but am wondering if anyone has suggestions to make this more succinct.

Here's what I've got:

---@class TestClass
---@overload fun(self: self, param: string): self   -- 2a
---@overload fun(            param: string): self   -- 2b
local TestClass = Class(function(self, param)       -- 1
	---@class TestClass          -- 3b
	self = self                  -- 3c

	self.field_constr = param    -- 3a
end)

function TestClass:Bar()
	self.field_meth = "a"        -- 4
end

local test_inst = TestClass("b")

Okay, kind of awkward. Let's talk about what I've got here.

1. You can see here our class factory taking the lambda for the constructor. The source of the problems.
2. Double overload! The first overload (2a) gets applied to the function on the next line (unexpectedly?) and gives us proper type information within the constructor. The second overload (2b) gets applied when instantiating the class TestClass("b")
3. HOWEVER: 3a creates a "fields can not be injected" warning, because it sees self as just a normal parameter. In order to fix this, I have to redeclare the class in this scope (3b) and then provide some variable to the declaration to attach to (3c). This is highly unfortunate.
4. Unexpectedly (?) fields injected in other methods don't have any complaints.

After doing this, the autocomplete on test_inst is .field_constr,.field_meth, and :Bar() as expected. If I leave out 3b/3c, then .field_constr is missing (because it was an illegal injection).

---

So my question is: Can anyone suggest any ways to clean up this mess? Ideally, 3a just works all the time, 3b and 3c are not necessary at all, and in a perfect world, 2a is not even necessary. We have tons of legacy code and so can not change the way our class system works, and are trying to find a compromise that gives us the best type information and the fewest warnings.

---

Edit: cleaned up unhelpful wordings.

[ipsquiggle]

In a perfect world, I feel like passing self: self in the overload should trigger the same behaviour as a method definition, in that it allows injection (opposed to passing t: TestClass would treat it as a normal parameter and prevent injection)...

[ipsquiggle]

Side note to this: What is the actual behaviour of the self type? It's undocumented and I discovered it by accident.