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

Suggestion: Const contexts for generic type inference #30680

Closed
5 tasks done
jcalz opened this issue Apr 1, 2019 · 19 comments · Fixed by #51865
Closed
5 tasks done

Suggestion: Const contexts for generic type inference #30680

jcalz opened this issue Apr 1, 2019 · 19 comments · Fixed by #51865
Labels
In Discussion Not yet reached consensus Suggestion An idea for TypeScript

Comments

@jcalz
Copy link
Contributor

jcalz commented Apr 1, 2019

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.

@RyanCavanaugh RyanCavanaugh added Suggestion An idea for TypeScript In Discussion Not yet reached consensus labels Apr 1, 2019
@aleclarson
Copy link

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

@sberan
Copy link

sberan commented May 4, 2019

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

jcalz commented Dec 22, 2019

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

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

@jcalz Thank you for the Narrowable workaround.

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

@jwulf
Copy link

jwulf commented Sep 30, 2020

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

@cyrilletuzi
Copy link

cyrilletuzi commented Oct 15, 2020

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

millsp commented Dec 30, 2020

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.

@KisaragiEffective
Copy link

KisaragiEffective commented Jun 1, 2021

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

jcalz commented Jun 8, 2021

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

@leoblum
Copy link

leoblum commented Jun 25, 2021

+1

@jcalz
Copy link
Contributor Author

jcalz commented Nov 28, 2021

Edited to reflect slightly different approach as mentioned in #46937

@captain-yossarian
Copy link

It would be great and make TS less verbose

@shigma
Copy link

shigma commented Apr 6, 2022

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

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

ExE-Boss commented Jul 5, 2022

@stephenh
Copy link

stephenh commented Nov 16, 2022

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

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
In Discussion Not yet reached consensus Suggestion An idea for TypeScript
Projects
None yet
Development

Successfully merging a pull request may close this issue.