Is this a bug? ---@operator eq shows unknown operator eq

[xiangnanscu]

---@class BaseField
---@overload fun(options: table): BaseField
---@operator add(BaseField): string
---@operator sub(BaseField): string
---@operator eq(BaseField): string
local BaseField = {}

[tomlau10]

It seems that eq / lt / le is not supported yet.
#599 (comment)

[C3pa]

Right, do we have an open issue for relational operators?

[tomlau10]

After reading the lua manual about Metatables and Metamethods, the result of a eq / lt / le will always be boolean. So I think there is no need to support that. 🤔
ref: https://www.lua.org/manual/5.3/manual.html#2.4

• __eq: the equal (==) operation. Behavior similar to the addition operation, except that Lua will try a metamethod only when the values being compared are either both tables or both full userdata and they are not primitively equal. The result of the call is always converted to a boolean.

---

At the first glance, I just get confused how come ---@operator eq(BaseField): string can specify it to return a string.
Is that doing a Basefield == Basefield => will return a string value?
But no, it will be converted to boolean.

Therefore it is enough for LuaLS to just infer the result as boolean type.
Or at most we can allow it in ---@operators, but they will be of NOP? 😕

[C3pa]

I agree that the resulting type seems wrong/unnecessary for boolean operators. But, what I consider useful in ---@operator annotations is that they allow specifying: yes, this type can be compared using these relational operators, and with given other type.

[tomlau10]

A quick patch to this would be allowing eq / lt / le in the unknown-operator diagnostics:

lua-language-server/script/core/diagnostics/unknown-operator.lua

Lines 23 to 26 in 40fd1d7

	local opName = op[1]
	if not vm.OP_BINARY_MAP[opName]
	and not vm.OP_UNARY_MAP[opName]
	and not vm.OP_OTHER_MAP[opName] then

say using a table { eq = true, lt = true, le = true } for skipping them.

A step further is also adding these operators in the autocompletion list (by following those vm. OP_BINARY_MAP implementation).
Then we can have these relational operators be defined, although they do nothing and will still be inferred as boolean when doing comparision 😂

[C3pa]

Then we can have these relational operators be defined, although they do nothing and will still be inferred as boolean when doing comparison

That's a good start. I've managed to find the issue about this: #1882.

I'd say that these operators would make sense if we had a new diagnostic that would warn the user that they are trying to compare variables with no defined < or == operator. Here is an example of what the Lua interpreter spits out when you try to compare two tables: https://onecompiler.com/lua/42njdete8.

Such a diagnostic would be useful in environments where the users have an OOP system implemented via metatables that also include comparison metamethods. So, the LLS could warn the user if the user tries to compare standard tables with such objects or objects of the wrong class. I suppose another way in which that diagnostic would be useful is for game engines that expose their internal classes to Lua via its userdata type that may have comparison operators.