Suggestion: Const contexts for generic type inference

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.

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

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)

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.

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.

Joe Calzaretta (@jcalz)

Joe Calzaretta (@jcalz) Thank you for the Narrowable workaround.

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

Sam Beran (@sberan)

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

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 ts@3.5 (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.

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.

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

+1

Edited 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 T and in out const T constraints.

pierre (@millsp)

pierre (@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']}]}

Navigation Menu

Repository navigation

Suggestion: Const contexts for generic type inference #30680

Search Terms

Suggestion

Related issues

Checklist

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Suggestion: Const contexts for generic type inference #30680

Description

Search Terms

Suggestion

Related issues

Checklist

Activity

aleclarson commented on Apr 5, 2019

sberan commented on May 4, 2019

jcalz commented on Dec 22, 2019

arciisine commented on Dec 22, 2019

dirkluijk commented on Jan 23, 2020

jwulf commented on Sep 30, 2020

cyrilletuzi commented on Oct 15, 2020

millsp commented on Dec 30, 2020

KisaragiEffective commented on Jun 1, 2021

jcalz commented on Jun 8, 2021

leoblum commented on Jun 25, 2021

jcalz commented on Nov 28, 2021

captain-yossarian commented on Feb 5, 2022

shigma commented on Apr 6, 2022

yujiosaka commented on Jun 21, 2022

ExE-Boss commented on Jul 5, 2022

stephenh commented on Nov 16, 2022

Andarist commented on Nov 16, 2022

stephenh commented on Nov 16, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions