Repository navigation
Suggestion: Const contexts for generic type inference #30680
Description
Activity
This would allow forcing a generic parameter to be inferred as a tuple instead of an array. 👍
Reacted by Zachiah Sawyer, Ethan Standel, James Bromwell, Jarrod Davis, Corentin Girard and Maciek SakrejdaThis would be incredible. I have an API for json schema which currently requires the caller to type
as consteverywhere:// $ExpectType Schema<string> schema({ type: ['string'] } as const) // $ExpectType Schema<string | number> schema({ type: ['string', 'number'] } as const)
Reacted by Leo, falfia falfiya, Trevin Miller, Thundercraft5, roblframpton and Maciek SakrejdaRelevant SO question: Dynamically generate return type based on array parameter of objects in TypeScript
My current answer involves adding a dummy type parameter
S extends stringto get string literal narrowing to happen in a different type parameterT extends {fieldName: S}; it reminded me that it would be so nice to have some more transparent syntax likeT extends {fieldName: const string}(or something) here.Reacted by Titian Cernicova-Dragomir and PilouClosed #35821 in lieu of this. To expand upon this issue, I would also like to have support for this in Javascript, as
as constis not applicable outside of.tsfiles.Joe Calzaretta (@jcalz) Thank you for the
Narrowableworkaround.I need this as well, to infer string literals or enum values in generics.
Another relevant SO question: https://stackoverflow.com/questions/64056538/type-signature-that-infers-all-values
Reacted by Bruno FantauzziWhat is the status of this? I have the same issue as Sam Beran (@sberan): inferring the type from a JSON Schema would currently require
as consteverywhere on the caller side:interface JsonSchemaNumber { type: 'number'; } interface JsonSchemaString { type: 'string'; } type JsonSchema = JsonSchemaNumber | JsonSchemaString; type SchemaToType<Schema extends JsonSchema> = Schema extends { type: 'string' } ? string : Schema extends { type: 'number' } ? number : unknown; function test<T extends JsonSchema>(schema: T): SchemaToType<T> | void { if (schema) {} } const int = { type: 'number' }; test(int);
Fails on function calling parameter with error:
Argument of type '{ type: string; }' is not assignable to parameter of type 'JsonSchema'. Type '{ type: string; }' is not assignable to type 'JsonSchemaString'. Types of property 'type' are incompatible. Type 'string' is not assignable to type '"string"'.While the following work:
const int = { type: 'number' } as const; test(int);
Meaning the caller must do
as consteverywhere, which is not a reasonable option.Reacted by Jonas, Bo Lingen, roblframpton and Maciek SakrejdaHi all,
I think that I have finally solved this puzzle. We can now control const contexts on the behalf of the user. There we go:
declare function foo<A>(x: Narrow<A>): A; declare function bar<A extends object>(x: Narrow<A>): A; const test0 = foo({a: 1, b: 'c', d: ['e', 2, true, {f: ['g']}]}); // `A` inferred : {a: 1, b: 'c', d: ['e', 2, true, {f: ['g']}]} const test1 = bar({a: 1, b: 'c', d: ['e', 2, true, {f: ['g']}]}); // `A` inferred : {a: 1, b: 'c', d: ['e', 2, true, {f: ['g']}]} const test3 = foo('hello jcalz <3'); // `A` inferred : 'hello jcalz <3' type Cast<A, B> = A extends B ? A : B; type Narrowable = | string | number | bigint | boolean; type Narrow<A> = Cast<A, | [] | (A extends Narrowable ? A : never) | ({ [K in keyof A]: Narrow<A[K]> }) >; // 🧙 what sorcery is this now?? 🧙
This will land soon in https://github.com/millsp/ts-toolbelt
The advantage of this vs
as constis that it can be used dynamically and works all the way down tots@3.5(inclusive)Not sure if
Constis an appropriate name here since it does not make anything const, that's up to you to useReadonly. Maybe calling itSelforNarrowwould be more concise. It solves the same problem described in the OP, nevertheless.Reacted by Tyler Murphy and YiJieReacted by Toni Villena, Stephen Haberman, Sam Beran, Steven "Slam" Lam, tienvudev, Jens Döllmann, Mateusz Burzyński, Jack Scott, Aria Buckles, Fernando Rojo and 11 moreReacted by Toni Villena, Sam Beran, Asger Hallas, tienvudev, Lenz Weber-Tronic, Jack Scott, Fernando Rojo, Samer, Sagnik Pradhan, roblframpton and 4 moreReacted by Toni Villena, Sam Beran, tienvudev and Thundercraft5Reacted by reiv, Sam Beran, tienvudev, Jo and Thundercraft5maybe make
Narrowed<T>isintrinsicand implement intsc?
If so, the imaginary -function x<T>(a: Narrowed<T>): foocan be implemented well.Reacted by __ and Mateusz BurzyńskiAnother SO question: Converting values in a dictionary to literal values
+1
Reacted by Bo Lingen, egon, David Enke, Mindful Design and KisaragiEdited to reflect slightly different approach as mentioned in #46937
It would be great and make TS less verbose
#48240 provides an excellent example of type annotations. now I would prefer
<const T>.thus we can also have
in const Tandin out const Tconstraints.Reacted by martinwepnerReacted by YiJiepierre (@millsp) 's solution solved most of my problems like a charm!
But I want to share one corner case to push this issue forward, which is providing a library to anonymous people.
Although the
Narrowtype works when you pass the argument directly to functions,
it does not work, of course, when the argument is defined beforehand without const assertion.declare function foo<A>(x: Narrow<A>): A; declare function bar<A extends object>(x: Narrow<A>): A; const param0 = {a: 1, b: 'c', d: ['e', 2, true, {f: ['g']}]}; const test0 = foo(param0); // not inferred as : {a: 1, b: 'c', d: ['e', 2, true, {f: ['g']}]} // but inferred as : {a: number, b: string, d: (string | number | boolean | {f: string[]})[]} type Cast<A, B> = A extends B ? A : B; type Narrowable = | string | number | bigint | boolean; type Narrow<A> = Cast<A, | [] | (A extends Narrowable ? A : never) | ({ [K in keyof A]: Narrow<A[K]> }) >;
If it's an internal project, you can ask your teammates to always pass arguments directly.
It's certainly much easier than forcing them to passas constin every function call.But when you are providing a library, people may not follow your advice always.
What I expect with this proposal is that following code fails to compile because passed argument can be modified (thus the types cannot be narrowed).
declare function baz<const T extends object>(x: T): T; // I don't have a preference in which style const param0 = {a: 1, b: 'c', d: ['e', 2, true, {f: ['g']}]}; const test0 = foo(param0); // it shouldn't compile
It should accept const argument.
declare function baz<const T extends object>(x: T): T; const param0 = {a: 1, b: 'c', d: ['e', 2, true, {f: ['g']}]} as const; const test0 = foo(param0); // inferred as : {a: 1, b: 'c', d: ['e', 2, true, {f: ['g']}]}
Also it would be nice if it automatically asserts argument as const when it's passed directly to the function (as originally proposed in this issue).
declare function baz<const T extends object>(x: T): T; const test0 = foo({a: 1, b: 'c', d: ['e', 2, true, {f: ['g']}]}); // inferred as : {a: 1, b: 'c', d: ['e', 2, true, {f: ['g']}]}
Reacted by falfia falfiya and Thundercraft5Fwiw I'm upgrading my project to TypeScript 4.9 and pierre (@millsp) 's
Constsolution is no longer working for me...I had been using a pattern like:
const a1 = await em.load(Author, "1", { publisher: {}, books: { reviews: "book" } }); expect(a1.publisher.get).toEqual(undefined);Where the 2nd param to
em.loadwould stay aconstby using theConsttype:public async load<T extends Entity, H extends LoadHint<T>>( type: EntityConstructor<T>, id: string, populate: Const<H>, ): Promise<Loaded<T, H>>;Which would get
a1inferred asLoaded<Author, { publisher: {}, books: ... }>, which allowed thea1.publisher.getcall to be legal.But now with TS 4.9.3,
a1is instead getting inferred asLoaded<Author, LoadHint<Author>>, which makes the.getcall break.I can fix/force it by adding
as constto call sites:const a1 = await em.load(Author, "1", { publisher: {}, books: { reviews: "book" } } as const);Which is going to be really verbose.
As anyone noticed
Constnot working for them on TS 4.9, and if so, any working fixes?Thanks!
...
Huh, I'm surprised, the 1st "poke something simple and see what happens" got it by to working for my specific use cases by removing
voidandnullfrom theNarrowable:type Narrowable = string | number | boolean | symbol | object | undefined | {} | []; export type Const<N> = | N | { [K in keyof N]: N[K] extends Narrowable ? N[K] | Const<N[K]> : never; };What seems odd is I have to remove both
voidandnull; if I leave either, then it goes back to not working. ...so, that's good for me I guess, b/c I don't needvoidornullin the load hints that I'mConst-izing. 🤔 🤷Reacted by Toni VillenaIt would be best if you could share a full inspectable TS playground with a report like this. It's hard to know what exactly might have changed if you don't share a repro case.
Ah hey Mateusz Burzyński (@Andarist) ! Yeah, that's a very fair ask; I was admittedly being lazy and hoping someone would have already hit an error and had a new/updated snippet.
I'll work on a playground-able repro of my issue.
Reacted by pierre and Kisaragi
Search Terms
const contexts; literals; narrowing; generics;
Suggestion
Allow const contexts for generic type parameter inference.
Often I've written and seen generic functions where the type parameter inference is intended to be as narrow as possible. Accomplishing this involves several "tricks" with generic constraints. It is more reminiscent of alchemy than I would like, and places quite a burden on the function signature and anyone with the misfortune of having to read and understand it:
Const contexts (#29510) are exactly the knob we want to turn here, and the "
as const" syntaxis succinct, understandable, and non-mind-bending. Unfortunately, the only way to use this in
generic functions is from the caller's side, which is hard to guarantee:
The suggestion here is to get the best of both worlds by allowing a const context to be specified in the generic type parameter declaration:
Related issues
#29510: const contexts
#10676: generics infer literals "T extends string | number | boolean"
#27179: generics infer tuples "T extends U[] | [U]"
#13347: probably can't make generics infer readonly
#16896: please narrow all object literals as much as possible
Checklist
My suggestion meets these guidelines:
EDIT: mentioning slightly different approach from #46937 where modifier goes on the type parameter instead of its constraint. It's not obvious to me if one has an advantage over the other.