We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
literal string, const literals, infer literals
My suggestion meets these guidelines:
const x: const string = "abc" // passes const y = "adsf" as string const y2: const string = y // fails function f<T extends const string>(t: T) {} const x = 'abc' as const f(x) // passes f(x as string) // error function f<T extends const string[]>(...t: T) {} const xs = ["a", "b", "c"] f(...xs) // passes f(...xs as ["a", string, "c"]) // fails function f<T extends [string, const string]>(...t: T) {} const a = "a" const s = some_str f(a, s) // fails f(s, a) // passes
The same applies to numbers.
I want to define an API for users to specify a fixed path in an object, consider
type Obj = { a: { b: { c: "123" } } } type Get<T, K> = K extends keyof T ? NonNullable<T[K]> : never type GetPath<T, P> = P extends PathKey[] ? P extends [] ? T // If P is empty, return T. : P extends [infer K, ...infer Rest] ? GetPath<Get<T, K>, Rest> // Else, recurse. : never : never function set<T, P extends string[]>(obj: T, path: P, value: GetPath<T, P>) {} set( obj, ["a", "b", "c"], value )
Currently, typescript would infer this set call's P as string[], hence value will be inferred as never.
set
P
string[]
never
This however, works when P extends string, so one way of doing this would be
P extends string
function set<T, P extends string>(obj: T, path: [P], value: unknown) {} function set<T, P1 extends string, P2 extends string>(obj: T, path: [P1, P2], value: unknown) {} function set<T, P1 extends string, P2 extends string, P3 extends string>(obj: T, path: [P1, P2, P3], value: unknown) {} // ...
This feels both cumbersome and not scalable.
With the proposed change, it'll look like
funciton set<T, P extends const string[]>(obj: T, path: P, value: GetPath<T, P> {}
On the other hand, sometimes people do want their generics to be inferred as string, not the literal passed in.
string
Allowing a const bound would allow developers to express precisely what they want.
const
The text was updated successfully, but these errors were encountered:
Looks like a duplicate of #51513
Sorry, something went wrong.
True. Mine's syntax is a bit more inclusive with the support of const ??? and const string[], but the crux is the same.
const ???
const string[]
Almost exactly like what #41114 is proposing :)
This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.
No branches or pull requests
Suggestion
π Search Terms
literal string, const literals, infer literals
β Viability Checklist
My suggestion meets these guidelines:
β Suggestion
The same applies to numbers.
π Motivating Example
I want to define an API for users to specify a fixed path in an object, consider
Currently, typescript would infer this
set
call'sP
asstring[]
, hence value will be inferred asnever
.This however, works when
P extends string
, so one way of doing this would beThis feels both cumbersome and not scalable.
With the proposed change, it'll look like
On the other hand, sometimes people do want their generics to be inferred as
string
, not the literal passed in.Allowing a
const
bound would allow developers to express precisely what they want.π» Use Cases
The text was updated successfully, but these errors were encountered: