Generics Super Issue - Githubissues

carsakiller commented 1 year ago

This "super issue" serves to organize and track all the issues relating to the implementation of generics.

Some of the following issues are likely duplicates, so some may just need to be marked duplicate and linked to other issues.

bandaloo commented 1 year ago

thanks for putting all these in one place. i found some more edge cases; maybe some of them are listed here already but i'll try to document them more diligently.

jakitliang commented 11 months ago

When will it get done?

tmillr commented 9 months ago

Here's another issue with generics that I don't believe has been documented yet?

---@class A
---@field k string

---@generic T: A
---@param p1 T
function f(p1) local m = p1.k end

^^^ here p1 should have a type of A within the function, but it doesn't, therefore m receives the type unknown

checkraisefold commented 4 months ago

Here's another issue with generics that I don't believe has been documented yet?
---@class A
---@field k string

---@generic T: A
---@param p1 T
function f(p1) local m = p1.k end
^^^ here p1 should have a type of A within the function, but it doesn't, so m receives the type unknown

This is odd since this use case works but you have to use the parameter capture for the generic to get its type and it also only works with base Lua types and not custom classes see #2355 description

tmillr commented 4 months ago

Here's another issue with generics that I don't believe has been documented yet?
---@class A
---@field k string

---@generic T: A
---@param p1 T
function f(p1) local m = p1.k end
^^^ here p1 should have a type of A within the function, but it doesn't, so m receives the type unknown
This is odd since this use case works but you have to use the parameter capture for the generic to get its type and it also only works with base Lua types and not custom classes see #2355 description

I wouldn't really consider that to be "working". Passing strings at runtime just to get the LSP to work correctly is awkward. In theory this should be an easy fix, as the concrete type is literally right there and apart of the function's signature. It's not much different than getting/substituting the type of a concrete @param, there's just an extra layer of indirection (i.e. p1 -> T -> A instead of p1 -> T).

checkraisefold commented 4 months ago

Here's another issue with generics that I don't believe has been documented yet?
---@class A
---@field k string

---@generic T: A
---@param p1 T
function f(p1) local m = p1.k end
^^^ here p1 should have a type of A within the function, but it doesn't, so m receives the type unknown
This is odd since this use case works but you have to use the parameter capture for the generic to get its type and it also only works with base Lua types and not custom classes see #2355 description
I wouldn't really consider that to be "working". Passing strings at runtime just to get the LSP to work correctly is awkward. In theory this should be an easy fix, as the concrete type is literally right there and apart of the function's signature. It's not much different than getting/substituting the type of a concrete @param, there's just an extra layer of indirection (i.e. p1 -> T -> A instead of p1 -> T).

Oh yeah, definitely not "working" per se but very odd that it works with strings and only base Lua types. I would think it would literally be easier to implement the other way code wise

AserJoker commented 2 months ago

how to implement like

//  typescript interface
interface A<T>{
next<K>(callback:(value:T)=>K):A<K>;
};

or not support now

LuaLS / lua-language-server

Generics Super Issue #1861