Add `NoInfer<T>` intrinsic represented as special substitution type by ahejlsberg · Pull Request #56794 · microsoft/TypeScript

Anders Hejlsberg (ahejlsberg) · 2023-12-15T17:48:40Z

This PR adds official support for a NoInfer<T> marker type that blocks inferences to the contained type. The PR supersedes #52968, but borrows as much as possible from that PR (lots of thanks for your work, Mateusz Burzyński (@Andarist)).

The PR represents NoInfer<T> types as special substitution types (types with kind TypeFlags.Substitution) having constraint type unknown, a pattern that otherwise never occurs. This representation ensures that we maximally leverage our existing infrastructure for erasing marker types when appropriate, and that we minimally disrupt the tooling ecosystem (because we're not introducing a new kind of type).

Other than blocking inference, NoInfer<T> markers have no effect on T. Indeed, T and NoInfer<T> are considered identical types in all other contexts.

Some examples:

declarefunctionfoo1<Textendsstring>(a: T,b: NoInfer<T>): voiddeclarefunctionfoo2<Textendsstring>(a: T,b: NoInfer<T>[]): voiddeclarefunctionfoo3<Textendsstring>(a: T,b: NoInfer<T[]>): voiddeclarefunctionfoo4<Textendsstring>(a: T,b: {x: NoInfer<T>}): voiddeclarefunctionfoo5<Textendsstring>(a: T,b: NoInfer<{x: T}>): voidfoo1('foo','foo')// okfoo1('foo','bar')// errorfoo2('foo',['bar'])// errorfoo3('foo',['bar'])// errorfoo4('foo',{x: 'bar'})// errorfoo5('foo',{x: 'bar'})// error

Above, inferences to the type of b are blocked by the NoInfer<T> marker, thus causing errors to be reported when the argument types differ. Without the NoInfer<T> markers, inference simply produces the union "foo" | "bar".

Fixes#14829.

Andrew Branch (andrewbranch) · 2023-12-15T19:14:16Z

TypeScript Bot (@typescript-bot) pack this

TypeScript Bot (typescript-bot) · 2023-12-15T19:14:20Z

Heya Andrew Branch (@andrewbranch), I've started to run the tarball bundle task on this PR at b25bf3e. You can monitor the build here.

TypeScript Bot (typescript-bot) · 2023-12-15T19:15:59Z

Hey Andrew Branch (@andrewbranch), I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
"devDependencies": {
"typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/159118/artifacts?artifactName=tgz&fileId=5E32343F3417330FFC1CCF4A8C1947A145A2ECCA7D11F2B39089E255FAC22AD202&fileName=/typescript-5.4.0-insiders.20231215.tgz"
}
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@5.4.0-pr-56794-2".;

Mateusz Burzyński (Andarist) · 2023-12-15T19:26:25Z

 Lowercase: IntrinsicTypeKind.Lowercase,
 Capitalize: IntrinsicTypeKind.Capitalize,
 Uncapitalize: IntrinsicTypeKind.Uncapitalize,
+ NoInfer: IntrinsicTypeKind.NoInfer,


Slightly related question: should ThisType become an intrinsic type as well (it is kinda intrinsic by nature but it's not defined as such in the typedefs)? Or is it better to not touch it at all?

Obviously this shouldn't be touched as part of this PR - I just take this opportunity to ask a question about it ;p

We want to leave ThisType as is. An intrinsic declaration doesn't really say anything about the internal representation of the type, and we already have a perfectly good solution for that with the current interface-based declaration.

Anders Hejlsberg (ahejlsberg) · 2023-12-15T19:29:08Z

TypeScript Bot (@typescript-bot) test top100
TypeScript Bot (@typescript-bot) user test this
TypeScript Bot (@typescript-bot) run dt
TypeScript Bot (@typescript-bot) perf test this faster

TypeScript Bot (typescript-bot) · 2023-12-15T19:29:11Z

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the tsc-only perf test suite on this PR at b25bf3e. You can monitor the build here.

Update: The results are in!

TypeScript Bot (typescript-bot) · 2023-12-15T19:29:11Z

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the diff-based user code test suite on this PR at b25bf3e. You can monitor the build here.

Update: The results are in!

TypeScript Bot (typescript-bot) · 2023-12-15T19:29:11Z

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the diff-based top-repos suite on this PR at b25bf3e. You can monitor the build here.

Update: The results are in!

TypeScript Bot (typescript-bot) · 2023-12-15T19:29:11Z

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the parallelized Definitely Typed test suite on this PR at b25bf3e. You can monitor the build here.

Update: The results are in!

TypeScript Bot (typescript-bot) · 2023-12-15T19:41:36Z

Anders Hejlsberg (@ahejlsberg)
The results of the perf run you requested are in!

Here they are:

Compiler

Comparison Report - baseline..pr

_Metric	_baseline	_pr	_Delta	_Best	_Worst	_p-value
_{Angular - node (v18.15.0, x64)}
_{Memory used}	_{295,417k (± 0.01%)}	_{295,473k (± 0.01%)}	_{+55k (+ 0.02%)}	_295,421k	_295,503k	_{p=0.013 n=6}
_{Parse Time}	_{2.65s (± 0.19%)}	_{2.65s (± 0.21%)}	_~	_2.64s	_2.65s	_{p=0.640 n=6}
_{Bind Time}	_{0.82s (± 0.00%)}	_{0.83s (± 0.62%)}	_{+0.01s (+ 0.81%)}	_0.82s	_0.83s	_{p=0.025 n=6}
_{Check Time}	_{8.14s (± 0.33%)}	_{8.13s (± 0.18%)}	_~	_8.12s	_8.16s	_{p=0.410 n=6}
_{Emit Time}	_{7.11s (± 0.35%)}	_{7.11s (± 0.23%)}	_~	_7.09s	_7.14s	_{p=0.505 n=6}
_{Total Time}	_{18.72s (± 0.19%)}	_{18.71s (± 0.16%)}	_~	_18.68s	_18.77s	_{p=0.629 n=6}
_{Compiler-Unions - node (v18.15.0, x64)}
_{Memory used}	_{194,424k (± 1.62%)}	_{193,481k (± 1.56%)}	_~	_191,529k	_197,409k	_{p=0.378 n=6}
_{Parse Time}	_{1.34s (± 1.13%)}	_{1.35s (± 0.00%)}	_~	_1.35s	_1.35s	_{p=0.293 n=6}
_{Bind Time}	_{0.72s (± 0.00%)}	_{0.72s (± 0.00%)}	_~	_0.72s	_0.72s	_{p=1.000 n=6}
_{Check Time}	_{9.25s (± 0.30%)}	_{9.26s (± 0.35%)}	_~	_9.22s	_9.29s	_{p=0.465 n=6}
_{Emit Time}	_{2.63s (± 0.56%)}	_{2.63s (± 0.31%)}	_~	_2.62s	_2.64s	_{p=0.666 n=6}
_{Total Time}	_{13.95s (± 0.30%)}	_{13.96s (± 0.18%)}	_~	_13.93s	_13.99s	_{p=0.685 n=6}
_{Monaco - node (v18.15.0, x64)}
_{Memory used}	_{347,392k (± 0.01%)}	_{347,390k (± 0.00%)}	_~	_347,375k	_347,408k	_{p=1.000 n=6}
_{Parse Time}	_{2.46s (± 0.60%)}	_{2.46s (± 0.33%)}	_~	_2.45s	_2.47s	_{p=1.000 n=6}
_{Bind Time}	_{0.92s (± 0.90%)}	_{0.93s (± 0.44%)}	_~	_0.92s	_0.93s	_{p=0.285 n=6}
_{Check Time}	_{6.90s (± 0.21%)}	_{6.88s (± 0.39%)}	_~	_6.86s	_6.93s	_{p=0.221 n=6}
_{Emit Time}	_{4.06s (± 0.20%)}	_{4.06s (± 0.56%)}	_~	_4.03s	_4.08s	_{p=1.000 n=6}
_{Total Time}	_{14.34s (± 0.17%)}	_{14.33s (± 0.26%)}	_~	_14.28s	_14.38s	_{p=0.517 n=6}
_{TFS - node (v18.15.0, x64)}
_{Memory used}	_{302,658k (± 0.00%)}	_{302,669k (± 0.00%)}	_~	_302,657k	_302,678k	_{p=0.108 n=6}
_{Parse Time}	_{2.00s (± 0.71%)}	_{2.00s (± 1.03%)}	_~	_1.96s	_2.02s	_{p=1.000 n=6}
_{Bind Time}	_{1.00s (± 1.17%)}	_{1.01s (± 0.97%)}	_~	_1.00s	_1.02s	_{p=0.066 n=6}
_{Check Time}	_{6.28s (± 0.25%)}	_{6.27s (± 0.41%)}	_~	_6.23s	_6.29s	_{p=0.569 n=6}
_{Emit Time}	_{3.59s (± 0.48%)}	_{3.58s (± 0.34%)}	_~	_3.56s	_3.59s	_{p=0.548 n=6}
_{Total Time}	_{12.86s (± 0.28%)}	_{12.85s (± 0.15%)}	_~	_12.82s	_12.87s	_{p=0.744 n=6}
_{material-ui - node (v18.15.0, x64)}
_{Memory used}	_{506,811k (± 0.01%)}	_{506,831k (± 0.00%)}	_~	_506,819k	_506,836k	_{p=0.127 n=6}
_{Parse Time}	_{2.59s (± 0.62%)}	_{2.58s (± 0.77%)}	_~	_2.54s	_2.60s	_{p=0.328 n=6}
_{Bind Time}	_{0.98s (± 1.06%)}	_{1.00s (± 0.52%)}	_~	_0.99s	_1.00s	_{p=0.051 n=6}
_{Check Time}	_{16.89s (± 0.21%)}	_{17.00s (± 0.55%)}	_~	_16.89s	_17.10s	_{p=0.065 n=6}
_{Emit Time}	_{0.00s (± 0.00%)}	_{0.00s (± 0.00%)}	_~	_0.00s	_0.00s	_{p=1.000 n=6}
_{Total Time}	_{20.46s (± 0.22%)}	_{20.57s (± 0.46%)}	_~	_20.47s	_20.67s	_{p=0.063 n=6}
_{xstate - node (v18.15.0, x64)}
_{Memory used}	_{512,794k (± 0.01%)}	_{512,848k (± 0.01%)}	_~	_512,788k	_512,916k	_{p=0.066 n=6}
_{Parse Time}	_{3.27s (± 0.32%)}	_{3.27s (± 0.16%)}	_~	_3.27s	_3.28s	_{p=0.242 n=6}
_{Bind Time}	_{1.54s (± 0.53%)}	_{1.54s (± 0.36%)}	_~	_1.53s	_1.54s	_{p=0.859 n=6}
_{Check Time}	_{2.82s (± 0.27%)}	_{2.84s (± 0.50%)}	_{+0.02s (+ 0.77%)}	_2.82s	_2.86s	_{p=0.009 n=6}
_{Emit Time}	_{0.07s (± 0.00%)}	_{0.08s (± 9.21%)}	_{🔻+0.01s (+16.67%)}	_0.07s	_0.09s	_{p=0.009 n=6}
_{Total Time}	_{7.69s (± 0.13%)}	_{7.73s (± 0.28%)}	_{+0.04s (+ 0.52%)}	_7.71s	_7.76s	_{p=0.005 n=6}

System info unknown

Hosts

node (v18.15.0, x64)

Scenarios

Angular - node (v18.15.0, x64)
Compiler-Unions - node (v18.15.0, x64)
Monaco - node (v18.15.0, x64)
TFS - node (v18.15.0, x64)
material-ui - node (v18.15.0, x64)
xstate - node (v18.15.0, x64)

_Benchmark	_Name	_Iterations
_Current	_pr	₆
_Baseline	_baseline	₆

Developer Information:

Download Benchmarks

TypeScript Bot (typescript-bot) · 2023-12-15T19:47:29Z

Anders Hejlsberg (@ahejlsberg) Here are the results of running the user test suite comparing main and refs/pull/56794/merge:

There were infrastructure failures potentially unrelated to your change:

1 instance of "Package install failed"

Otherwise...

Something interesting changed - please have a look.

Details

puppeteer

packages/browsers/test/src/tsconfig.json

[MISSING] error TS2307: Cannot find module '@pptr/testserver' or its corresponding type declarations.
- packages/browsers/test/src/utils.ts#L23 in packages/browsers/test/src/tsconfig.json

TypeScript Bot (typescript-bot) · 2023-12-15T20:01:45Z

Hey Anders Hejlsberg (@ahejlsberg), the results of running the DT tests are ready.
Everything looks the same!
You can check the log here.

Bruce Pascoe (fatcerberus) · 2023-12-15T20:04:00Z

Without the NoInfer<T> markers, inference simply produces the union "foo" | "bar".

Huh, so it does... here I had thought TS never inferred cross-candidate unions, but apparently there are cases when it does?

Ryan Cavanaugh (RyanCavanaugh) · 2023-12-15T20:10:33Z

Unions can be formed under the same constrained primitive family. That's why my TS Congress talk had to disavow knowledge of primitive types.

TypeScript Bot (typescript-bot) · 2023-12-15T20:38:21Z

Anders Hejlsberg (@ahejlsberg) Here are the results of running the top-repos suite comparing main and refs/pull/56794/merge:

Everything looks good!

Anders Hejlsberg (ahejlsberg) · 2023-12-16T01:31:08Z

Tests and performance all look unaffected.

Craig P Hicks (craigphicks) · 2023-12-17T22:28:08Z

Some examples:

declarefunctionfoo1<Textendsstring>(a: T,b: NoInfer<T>): voiddeclarefunctionfoo2<Textendsstring>(a: T,b: NoInfer<T>[]): voiddeclarefunctionfoo3<Textendsstring>(a: T,b: NoInfer<T[]>): voiddeclarefunctionfoo4<Textendsstring>(a: T,b: {x: NoInfer<T>}): voiddeclarefunctionfoo5<Textendsstring>(a: T,b: NoInfer<{x: T}>): voidfoo1('foo','foo')// okfoo1('foo','bar')// errorfoo2('foo',['bar'])// errorfoo3('foo',['bar'])// errorfoo4('foo',{x: 'bar'})// errorfoo5('foo',{x: 'bar'})// error

All these cases can be addressed by using extends as follows:

declare function foo1<T extends string, U extends T>(a: T, b: U): void
declare function foo2<T extends string, U extends T>(a: T, b: U): void
declare function foo3<T extends string, U extends T>(a: T, b: (U)[]): void
declare function foo4<T extends string, U extends T>(a: T, b: { x: U }): void
declare function foo5<T extends string, U extends T>(a: T, b: { x: U }): void
foo1('foo', 'foo') // ok
foo1('foo', 'bar') // error
foo2('foo', ['bar']) // error
foo3('foo', ['bar']) // error
foo4('foo', { x: 'bar' }) // error
foo5('foo', { x: 'bar' }) // error
declare function invoke<F extends ((value:any) => any)>(func:F, value: Parameters<F>["0"]): ReturnType<F>;
declare function test(value: { x: number; }): number;
invoke(test, { x: 1, y: 2 }); // Compiler Error
test({ x: 1, y: 2 }); // Same Compiler error

playground

It is not a trick. Do you have any stronger cases?

I would not call those test cases buggy. With only that evidence it seems like perhaps this pull is a performance optimization, because you are explicitly shutting down inference, which could only shorten processing time, which is not a bad thing at all.

Daniel Rosenwasser (DanielRosenwasser) · 2023-12-18T20:04:23Z

I have been summoned to summon TypeScript Bot.

TypeScript Bot (@typescript-bot) pack this

TypeScript Bot (typescript-bot) · 2023-12-18T20:04:26Z

Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to run the tarball bundle task on this PR at e492451. You can monitor the build here.

TypeScript Bot (typescript-bot) · 2023-12-18T20:06:09Z

Hey Daniel Rosenwasser (@DanielRosenwasser), I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
"devDependencies": {
"typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/159134/artifacts?artifactName=tgz&fileId=B8324752B810A78A78AD8A90EDD001B4CF0393014CE0810C88CFCE3F0DEB2DF202&fileName=/typescript-5.4.0-insiders.20231218.tgz"
}
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@5.4.0-pr-56794-29".;

Daniel Rosenwasser (DanielRosenwasser) · 2023-12-18T20:07:59Z

 if (type.flags & TypeFlags.Substitution) {
- return typeToTypeNodeHelper((type as SubstitutionType).baseType, context);
+ const typeNode = typeToTypeNodeHelper((type as SubstitutionType).baseType, context);
+ return isNoInferType(type) ? factory.createTypeReferenceNode("NoInfer", [typeNode]) : typeNode;


What happens in declaration emit when something like this gets serialized?
// foo.tsexportconstf: <T>(x: T,y: NoInfer<T>)=>bool;// bar.tsimport{f}from"./foo.js";typeNoInfer<T>=number;exportconstg=f;

With the latest commit this will now emit globalThis.NoInfer<T>, similar to what we do for other global types in conflict situations.

Do we have a test for that? Same with Uppercase etc.

We don't, at least not that I can tell.

Test added.

Craig P Hicks (craigphicks) · 2023-12-18T20:54:04Z

My gut feeling is that the infer vs noinfer attribute belongs to the call, rather than to the parameter types of the call.

I have to explain what I mean by "belongs to the call".

You might have a multiple parameter types that appears in multiple calls:

type X<T> {
id: "x"
a: T
b: (x: X<T>): T
};
type Y<T> {
id: "y"
a: T
b: (x: X<T>): T
};
type X<T> = {
id?: "x"
a: T
b: X<T>;
};
type Y<T> = {
id?: "y"
a: T
b: Y<T>
};
declare function fInferFromMemberA0<U, T extends U, Z extends X<U>|Y<U>>(z:Z): (x: T)=>Z;
declare function fInferFromMemberB0<U, T extends U, Z extends X<U>|Y<U>>(z:Z): (x: T)=>Z;
const ta01 = fInferFromMemberA0({a:1, b:0 as any as X<"">});
// does not infer typeof Z.a, but infers type of Z
//const ta01: (x: unknown) => { // a: number;
// b: X<"">;
// }
const ta02 = fInferFromMemberB0({a:1, b:0 as any as X<"">})
// does not infer type arg of typeof Z.b, but infers type of Z
// const ta02: (x: unknown) => {
// a: number;
// b: X<"">;
// }
declare function fInferFromMemberA1<U, T extends U, Z extends X<U>|Y<U> >(z:Z & {a:T}): (x: T)=>Z;
declare function fInferFromMemberB1<U, T extends U, Z extends X<U>|Y<U> >(z:Z & {b:X<T>|Y<T>}): (x: T)=>Z;
const ta11 = fInferFromMemberA1({a:1, b:0 as any as X<"">});
// infers both typeof Z.a, and type of Z
// const ta11: (x: number) => {
// a: number;
// b: X<"">;
// }
const ta12 = fInferFromMemberB1({a:1, b:0 as any as X<"">})
// infers both type arg of typeof Z.b, and type of Z
// const ta12: (x: "") => {
// a: number;
// b: X<"">;
// }

Trying to infer typeof Z.a in fInferFromMemberA0 does not work (regardless of NoInfer usage), although it could infer Z.

In order to infer typeof Z.a in fInferFromMemberA1, I had to add & {a:T} to function argument type (z:Z & {a:T}). Then it works correctly, and NoInfer wasn't used.

Switching to member Z.b works similarly.

The ability to reach into type structure to infer type from specified members could be useful, but NoInfer types do not make a difference to what is currently allowed. (I tried).

And if it did, the choice of which member to infer from is likely depend upon the function, not the parameter type passed.

Craig P Hicks (craigphicks) · 2023-12-19T00:36:52Z

Cases from 2.8 release documentation + NoInfer

type Foo<T> = T extends { a: infer U; b: NoInfer<infer U> } ? U : never;
type T10 = Foo<{ a: string; b: string }>; // string
type T11 = Foo<{ a: string; b: number }>; // never (expecting string)

type Bar<T> = T extends { a: (x: infer U) => void; b: (x: NoInfer< infer U>) => void }
? U
: never;
type T20 = Bar<{ a: (x: string) => void; b: (x: string) => void }>; // string
type T21 = Bar<{ a: (x: string) => void; b: (x: number) => void }>; // never (expecting string)

Try with predefined type

type X<U> = { a: U; b: NoInfer<U> };
type Foo<T> = T extends X<infer U> ? U : never;
type T10 = Foo<{ a: string; b: string }>; // string
type T11 = Foo<{ a: string; b: number }>; // never (expecting string)

type Y<U> = { a: (x: U) => void; b: (x: NoInfer<U>) => void }
type Bar<T> = T extends Y<infer U> ? U : never;
type T20 = Bar<{ a: (x: string) => void; b: (x: string) => void }>; // string
type T21 = Bar<{ a: (x: string) => void; b: (x: number) => void }>; // never (expecting string)

Anders Hejlsberg (ahejlsberg) · 2023-12-20T21:48:43Z

TypeScript Bot (@typescript-bot) pack this

TypeScript Bot (typescript-bot) · 2023-12-20T21:48:45Z

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the tarball bundle task on this PR at 2fc975a. You can monitor the build here.

TypeScript Bot (typescript-bot) · 2023-12-20T21:50:34Z

Hey Anders Hejlsberg (@ahejlsberg), I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
"devDependencies": {
"typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/159140/artifacts?artifactName=tgz&fileId=3D23A0C817DD7FA525E171E302DDA2643043A9E12BDAFB80A686389EE0054E4E02&fileName=/typescript-5.4.0-insiders.20231220.tgz"
}
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@5.4.0-pr-56794-34".;

Flavien Volken (Xample) · 2024-02-20T06:44:31Z

I'm surprised not to see more examples where the type is infered from the returned value. Here is a (simplified) real world example of a code I faced where it was unpossible to catch errors without the Noinfer keyworld :

// TS <5.4functiongetValue<T=string>(): T{returnundefinedasT;}functiongetNumberInline(): number{returngetValue();// no error, T in inferred as number (weird behavior)}functiongetNumberUsingVariable(): number{constvalue=getValue();// error, T takes the default string valuereturnvalue;}// TS >=5.4functiongetValueNoInfer<T=string>(): NoInfer<T>{returnundefinedasT;}functiongetNumberInlineNoInfer(): number{returngetValueNoInfer();// error, T takes the default string value}functiongetNumberUsingVariableNoInfer(): number{constvalue=getValueNoInfer();// error, T takes the default string valuereturnvalue;}

Dmitriy Verenich (dhmk083) · 2024-02-24T14:26:55Z

It would be nice if the following pattern could work:

declarefunctioncreate<T>(fn: (get: ()=>NoInfer<T>)=>T): Tcreate(get=>({id: 123,getId(){returnget().id}}))

Right now T is inferred as unknown.

If I understand NoInfer<T> correctly, it should give a hint to a compiler to not try to infer get-parameter type and instead infer T from type of returned object.

Flavien Volken (Xample) · 2024-02-24T14:51:45Z

Dmitriy Verenich (@dhmk083) shouldn't you write:

declarefunctioncreate<T>(fn: (get: ()=>NoInfer<T>)=>T): Tconstget=()=>({id: 123,getId(){returnget().id}})create(get)

Dmitriy Verenich (dhmk083) · 2024-02-24T16:10:18Z

No, it was just a simplified example. Here you can read about real world usage. (Check the first collapsible section Why can't we simply infer the type from the initial state?, I don't know how to link to it directly.)

Mateusz Burzyński (Andarist) · 2024-02-27T07:33:10Z

Dmitriy Verenich (@dhmk083) currently, TS can't defer this sufficiently enough, it has to assign the contextual type for get before it even looks into your function. To do that it instantiates the type of this parameter and all of the type parameters in its scope (and T is its outer type parameter).

It's probably not impossible to improve this by deferring the instantiation of those parameter types that are only observable by the return types. I don't feel that it's particularly related to NoInfer though.

And note that ur getId is circular (its return type depends on T) - so even if the type parameters used by return types would get deferred, it likely still wouldn't fix your problem entirely.

Anders Hejlsberg (ahejlsberg) added 3 commits December 15, 2023 08:52

Add NoInfer<T> intrinsic represented as special substitution type
ba7f084

Update tests
411205e

Add tests
b25bf3e

TypeScript Bot (typescript-bot) assigned Anders Hejlsberg (ahejlsberg)Dec 15, 2023

TypeScript Bot (typescript-bot) added Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug labels Dec 15, 2023

Anders Hejlsberg (ahejlsberg) added this to the TypeScript 5.4.0 milestone Dec 15, 2023

Mateusz Burzyński (Andarist) mentioned this pull request Dec 15, 2023
Add NoInfer intrinsic type #52968
Closed

Mateusz Burzyński (Andarist) reviewed Dec 15, 2023
View reviewed changes

This was referenced Dec 15, 2023
Design Meeting Notes, 12/13/2023 #56798
Closed
Design Meeting Notes, 12/15/2023 #56799
Closed

Anders Hejlsberg (ahejlsberg) requested review from Daniel Rosenwasser (DanielRosenwasser), Ryan Cavanaugh (RyanCavanaugh) and Andrew Branch (andrewbranch)December 16, 2023 01:31

Daniel Rosenwasser (DanielRosenwasser) reviewed Dec 18, 2023
View reviewed changes

Anders Hejlsberg (ahejlsberg) added 3 commits December 20, 2023 08:40

keyof NoInfer<T> ==> NoInfer<keyof T> / globalThis emit when needed
63b6713

Simplify keyof NoInfer<T> ==> NoInfer<keyof T> transformation
14b90c2

Update tests
2fc975a

Daniel Rosenwasser (DanielRosenwasser) mentioned this pull request Jan 4, 2024
TypeScript 5.4 Iteration Plan #56948
Closed

Anders Hejlsberg (ahejlsberg) added 2 commits January 9, 2024 10:12

Merge branch 'main' into fix14829
af2aae4

Add test for redeclaration of NoInfer<T>
79f8513

Andrew Branch (andrewbranch) approved these changes Jan 10, 2024
View reviewed changes

Anders Hejlsberg (ahejlsberg) merged commit e6fe96c into mainJan 12, 2024

Anders Hejlsberg (ahejlsberg) deleted the fix14829 branch January 12, 2024 21:59

Craig P Hicks (craigphicks) mentioned this pull request Jan 13, 2024
Functioning NoInfer behavior in generic conditional types #57050
Closed
6 tasks

Aaron Adams (aaronadamsCA) mentioned this pull request Feb 6, 2024
Improve GraphQL TypedDocumentNode usage in the new MSW.js version mswjs/msw#1881
Closed
1 task

Crow (echocrow) mentioned this pull request Feb 8, 2024
Meta-issue: Use Full Unification for Generic Inference? #30134
Open

Tyler (gittgott) mentioned this pull request Feb 18, 2024
Query param type safety only works for the first param. openapi-ts/openapi-typescript#1525
Open
1 task

Mateusz Burzyński (Andarist) mentioned this pull request Apr 23, 2024
Unwrap NoInfer types when narrowing #58292
Merged

Joe Calzaretta (jcalz) mentioned this pull request Oct 4, 2025
String literal type is always widened when used as a generic type parameter #41742
Closed

Microsoft (microsoft) locked as resolved and limited conversation to collaborators Oct 16, 2025

Uh oh!

Conversation

Anders Hejlsberg (ahejlsberg) commented Dec 15, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Andrew Branch (andrewbranch) commented Dec 15, 2023

Uh oh!

TypeScript Bot (typescript-bot) commented Dec 15, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TypeScript Bot (typescript-bot) commented Dec 15, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Anders Hejlsberg (ahejlsberg)Dec 15, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Anders Hejlsberg (ahejlsberg) commented Dec 15, 2023

Uh oh!

TypeScript Bot (typescript-bot) commented Dec 15, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TypeScript Bot (typescript-bot) commented Dec 15, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TypeScript Bot (typescript-bot) commented Dec 15, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TypeScript Bot (typescript-bot) commented Dec 15, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TypeScript Bot (typescript-bot) commented Dec 15, 2023

Compiler

Uh oh!

TypeScript Bot (typescript-bot) commented Dec 15, 2023

Uh oh!

TypeScript Bot (typescript-bot) commented Dec 15, 2023

Uh oh!

Bruce Pascoe (fatcerberus) commented Dec 15, 2023

Uh oh!

Ryan Cavanaugh (RyanCavanaugh) commented Dec 15, 2023

Uh oh!

TypeScript Bot (typescript-bot) commented Dec 15, 2023

Uh oh!

Anders Hejlsberg (ahejlsberg) commented Dec 16, 2023

Uh oh!

Craig P Hicks (craigphicks) commented Dec 17, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Daniel Rosenwasser (DanielRosenwasser) commented Dec 18, 2023

Uh oh!

TypeScript Bot (typescript-bot) commented Dec 18, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TypeScript Bot (typescript-bot) commented Dec 18, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Craig P Hicks (craigphicks) commented Dec 18, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Craig P Hicks (craigphicks) commented Dec 19, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Anders Hejlsberg (ahejlsberg) commented Dec 20, 2023

Uh oh!

TypeScript Bot (typescript-bot) commented Dec 20, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Anders Hejlsberg (ahejlsberg) commented Dec 15, 2023•
edited
Loading

TypeScript Bot (typescript-bot) commented Dec 15, 2023•
edited
Loading

TypeScript Bot (typescript-bot) commented Dec 15, 2023•
edited
Loading

Anders Hejlsberg (ahejlsberg)Dec 15, 2023•
edited
Loading

TypeScript Bot (typescript-bot) commented Dec 15, 2023•
edited
Loading

TypeScript Bot (typescript-bot) commented Dec 15, 2023•
edited
Loading

TypeScript Bot (typescript-bot) commented Dec 15, 2023•
edited
Loading

TypeScript Bot (typescript-bot) commented Dec 15, 2023•
edited
Loading

Craig P Hicks (craigphicks) commented Dec 17, 2023•
edited
Loading

TypeScript Bot (typescript-bot) commented Dec 18, 2023•
edited
Loading

TypeScript Bot (typescript-bot) commented Dec 18, 2023•
edited
Loading

Craig P Hicks (craigphicks) commented Dec 18, 2023•
edited
Loading

Craig P Hicks (craigphicks) commented Dec 19, 2023•
edited
Loading

TypeScript Bot (typescript-bot) commented Dec 20, 2023•
edited
Loading

TypeScript Bot (typescript-bot) commented Dec 20, 2023•
edited
Loading

Mateusz Burzyński (Andarist) commented Feb 27, 2024•
edited
Loading