Support for Operator type annotations

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?

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

@sumneko

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

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.

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

@Benjamin-Dobell

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

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.

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).

@sumneko

@sumneko any news? :)

Will support in 3.5.0

Done.

@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.

@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.

add: description for @operator LuaLS#599

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".

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 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?

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.

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

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.

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?

class Example: {[number]: number}

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

Navigation Menu

Repository navigation

Support for Operator type annotations #599

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support for Operator type annotations #599

Description

Activity

sumneko commented on Jul 15, 2021

Stanzilla commented on Jul 15, 2021

sumneko commented on Jul 16, 2021

Benjamin-Dobell commented on Jul 17, 2021

sumneko commented on Jul 19, 2021

Benjamin-Dobell commented on Jul 19, 2021

sumneko commented on Jul 19, 2021

Stanzilla commented on Jun 22, 2022

sumneko commented on Jun 23, 2022

sumneko commented on Jul 6, 2022

nathanpage-credo commented on Jul 7, 2022

sumneko commented on Jul 7, 2022

BribeFromTheHive commented on Nov 19, 2022

sumneko commented on Nov 21, 2022

CelticMinstrel commented on Feb 5, 2023

sumneko commented on Feb 6, 2023

CelticMinstrel commented on Feb 6, 2023

sumneko commented on Feb 6, 2023

luiz00martins commented on Nov 8, 2024

BribeFromTheHive commented on Nov 8, 2024

tomlau10 commented on Nov 8, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions