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

[sumneko]

Done.

[nathanpage-credo]

@sumneko Will this also support extending current classes/types. For example, I've used penlight stringx.format_operator which allows "%d %d" % {2,3}. This shows up as a param-type-mismatch.

[sumneko]

@sumneko Will this also support extending current classes/types. For example, I've used penlight stringx.format_operator which allows "%d %d" % {2,3}. This shows up as a param-type-mismatch.

Please open a new issue and tell more details.

[BribeFromTheHive]

How do I document an __index metamethod? I have a table which extends an arbitrary number of sub-elements via OriginalTableName.subElementName syntax. I have no idea how to tell the extension that the subElementNames are of type "blahBlahBlah" instead of it defaulting to "unknown".

[sumneko]

How do I document an __index metamethod? I have a table which extends an arbitrary number of sub-elements via OriginalTableName.subElementName syntax. I have no idea how to tell the extension that the subElementNames are of type "blahBlahBlah" instead of it defaulting to "unknown".

---@class Cat: Animal

[CelticMinstrel]

I have a question about the operator annotation. Is it also required if the operator metafunction is fully declared in the Lua file? Or is that detected separately?

[sumneko]

I have a question about the operator annotation. Is it also required if the operator metafunction is fully declared in the Lua file? Or is that detected separately?

Operator annotation is required.

[CelticMinstrel]

Another question. What about the comparison operators? That is, eq / lt / le. Currently it reports those to be an unknown operator.

[sumneko]

Another question. What about the comparison operators? That is, eq / lt / le. Currently it reports those to be an unknown operator.

Not supported yet.
If you have other questions or feature requests, please open a new issue.

[luiz00martins]

How do I document an __index metamethod? I have a table which extends an arbitrary number of sub-elements via OriginalTableName.subElementName syntax. I have no idea how to tell the extension that the subElementNames are of type "blahBlahBlah" instead of it defaulting to "unknown".

---@class Cat: Animal

I'm also trying to type the index operator in my class, but I didn't quite understand what this means. As an example:

---@class Example
---@operator call: string
---@field field fun(): number
local example = setmetatable({}, {
  __call = function(_, ...)
    return "a"
  end,
  __index = function(_, key)
    return 1
  end,
  field = function() return 2 end,
})

local a = example.field()
local b = example()
local c = example[1]

In the example above, a is correctly deduced as a number, and b is correctly deduced as a string, but c is unknown. Is it possible to make the LSP deduce c to be a number?

[BribeFromTheHive]

class Example: {[number]: number}

[tomlau10]

one can also use ---@field [KeyType] ValueType to define the index operation type

---@class Example
---@operator call: string
---@field field fun(): number
---@field [any] number
local example = {}

local a = example.field() -- number
local b = example() -- string
local c = example[1] -- number
local d = example['2'] -- number