Suggestion: Const contexts for generic type inference

[jcalz]

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:

// 🧙 what sorcery is this?? 🧙‍ 
type Narrowable = string | number | boolean | symbol | object | undefined | void | null | {};
declare function foo<N extends Narrowable, T extends { [k: string]: N | T | [] }>(x: T): T; 

foo({ a: 1, b: "c", d: ["e", 2, true, { f: "g" }] });
// T inferred as { a: 1; b: "c"; d: ["e", 2, true, { f: "g"; }]; }

Const contexts (#29510) are exactly the knob we want to turn here, and the "as const" syntax
is 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:

declare function bar<T extends object>(x: T): T; 
bar({ a: 1, b: "c", d: ["e", 2, true, { f: "g" }] } as const); // burden on function caller
// T inferred as { 
//   readonly a: 1; readonly b: "c"; d: readonly ["e", 2, true, { readonly f: "g"; }]; 
// }

bar({ a: 1, b: "c", d: ["e", 2, true, { f: "g" }] }); // oops!!
// T inferred as { 
//   a: number; b: string; d: (string | number | boolean | { f: string; })[]; 
// } 😢

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:

declare function baz<T extends const object>(x: T): T; // 🤔
declare function baz<T extends object as const>(x: T): T; // 🤷
declare function baz<const T extends object>(x: T): T; // 😵
declare function baz<const T const extends readonly object as const>(x: T): T; // 🧠💥🤪

// also possible, see #46937:
declare function baz<T extends object>(x: const T): T; 



baz({ a: 1, b: "c", d: ["e", 2, true, { f: "g" }] });
// T inferred as { 
//   readonly a: 1; readonly b: "c"; d: readonly ["e", 2, true, { readonly f: "g"; }]; 
// } ❤🎉

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:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

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.

[aleclarson]

This would allow forcing a generic parameter to be inferred as a tuple instead of an array. 👍

[sberan]

This would be incredible. I have an API for json schema which currently requires the caller to type as const everywhere:

// $ExpectType Schema<string>
schema({
  type: ['string']
} as const)

// $ExpectType Schema<string | number>
schema({
  type: ['string', 'number']
} as const)

[jcalz]

Relevant 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 string to get string literal narrowing to happen in a different type parameter T extends {fieldName: S}; it reminded me that it would be so nice to have some more transparent syntax like T extends {fieldName: const string} (or something) here.

[arciisine]

Closed #35821 in lieu of this. To expand upon this issue, I would also like to have support for this in Javascript, as as const is not applicable outside of .ts files.

[dirkluijk]

@jcalz Thank you for the Narrowable workaround.

I need this as well, to infer string literals or enum values in generics.

[jwulf]

Another relevant SO question: https://stackoverflow.com/questions/64056538/type-signature-that-infers-all-values

[cyrilletuzi]

What is the status of this? I have the same issue as @sberan: inferring the type from a JSON Schema would currently require as const everywhere 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 const everywhere, which is not a reasonable option.

[millsp]

Hi 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?? 🧙‍

Play it

This will land soon in https://github.com/millsp/ts-toolbelt

The advantage of this vs as const is that it can be used dynamically and works all the way down to [email protected] (inclusive)

Not sure if Const is an appropriate name here since it does not make anything const, that's up to you to use Readonly. Maybe calling it Self or Narrow would be more concise. It solves the same problem described in the OP, nevertheless.

[KisaragiEffective]

maybe make Narrowed<T> is intrinsic and implement in tsc?
If so, the imaginary - function x<T>(a: Narrowed<T>): foo can be implemented well.

[jcalz]

Another SO question: Converting values in a dictionary to literal values

[leoblum]

+1

[jcalz]

Edited to reflect slightly different approach as mentioned in #46937

[captain-yossarian]

It would be great and make TS less verbose

[shigma]

#48240 provides an excellent example of type annotations. now I would prefer <const T>.

thus we can also have in const T and in out const T constraints.

[yujiosaka]

@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 Narrow type 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]> })
>;

Playground

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 pass as const in 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']}]}

[ExE-Boss]

See also:

• Support readonly type operator to allow correct definition of Object.freeze #10725

[stephenh]

Fwiw I'm upgrading my project to TypeScript 4.9 and @millsp 's Const solution 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.load would stay a const by using the Const type:

  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 a1 inferred as Loaded<Author, { publisher: {}, books: ... }>, which allowed the a1.publisher.get call to be legal.

But now with TS 4.9.3, a1 is instead getting inferred as Loaded<Author, LoadHint<Author>>, which makes the .get call break.

I can fix/force it by adding as const to 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 Const not 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 void and null from the Narrowable:

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 void and null; if I leave either, then it goes back to not working. ...so, that's good for me I guess, b/c I don't need void or null in the load hints that I'm Const-izing. 🤔 🤷

[Andarist]

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

[stephenh]

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