Support for Operator type annotations

[Stanzilla]

It does not look like Emmy does have native support for Operator type annotations but I was wondering if it was possible to add it to the LSP?

[sumneko]

Considering performance issues, a new annotation should be provided for explicit marking.

[Stanzilla]

@sumneko but that is still something you can do inside of the LSP, right?

[sumneko]

My current assumption is this:

---@class A
---@operator add string

---@type A
local a
local r = a + 1 -- `r` is `string` here

For performance reasons, you must define this explicitly, otherwise the cost performance from metatable search is too low.

[Benjamin-Dobell]

May I please instead suggest:

unary_op ::= 'unm'
binary_op ::= 'add' | 'sub' | 'mul' | 'div' | 'idiv' | 'mod' | 'pow' | 'concat'
unary_operator ::= unary_op ':'? ty
binary_operator ::= binary_op '(' ty ')' ':' ty
tag_operator ::= 'operator' (unary_operator | binary_operator) comment_string?

In order to cover:

---@class A
---@operator unm: A
---@operator add(A): A
---@operator add(number): number

---@type A
local a1

---@type A
local a2

local foo = a1 + a2 -- A
local bar = a1 + 1 -- number
local huzzah = -a1 -- A

[sumneko]

@Benjamin-Dobell This kind of generic support may bring a relatively large overhead, I don’t want to support it for the time being

[Benjamin-Dobell]

Sorry, just to to clarify, I'm not requesting you add all those operators or that you infer the right operand's type. Instead I'd like to try come up with a syntax that is at least future proof with respect to types, in order to avoid the pitfalls of LDoc.

I'm the developer of Luanalysis. Luanalysis does not yet have this functionality but, when implemented, will use the right operand's type when inferring the resultant type of the expression. Even if you opt to ignore the right operand's type, it'd be ideal if we supported the same syntax.

[sumneko]

Sorry, just to to clarify, I'm not requesting you add all those operators. Instead I'd like to try come up with a syntax that is future proof with respect to types, in order to avoid the pitfalls of LDoc.

I'm the developer of Luanalysis. Luanalysis does not yet have this functionality but, when implemented, will use the right operand's type when inferring the resultant type of the expression. Even if you opt to ignore the right operand's type, it'd be ideal if we supported the same syntax.

It looks good, and I will follow this format to implement it later (including compatibility and ignoring the type of operation object).

[Stanzilla]

@sumneko any news? :)

[sumneko]

Will support in 3.5.0