Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generics Super Issue #1861

Open
1 of 15 tasks
carsakiller opened this issue Jan 30, 2023 · 7 comments
Open
1 of 15 tasks

Generics Super Issue #1861

carsakiller opened this issue Jan 30, 2023 · 7 comments
Labels
feat/generic Related to generic emulation feature

Comments

@carsakiller
Copy link
Collaborator

carsakiller commented Jan 30, 2023

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.

@carsakiller carsakiller added the feat/generic Related to generic emulation feature label Jan 30, 2023
@carsakiller carsakiller pinned this issue Jan 30, 2023
@bandaloo
Copy link

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
Copy link

When will it get done?

@tmillr
Copy link
Contributor

tmillr commented Jan 29, 2024

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
Copy link

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
Copy link
Contributor

tmillr commented Jul 10, 2024

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
Copy link

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
Copy link

how to implement like

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

or not support now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat/generic Related to generic emulation feature
Projects
None yet
Development

No branches or pull requests

6 participants