Implement partial type argument inference using the _ sigil

[Wesley Wigham (weswigham)]

In this PR, we allow the _ sigil to appear in type argument lists in expression positions as a placeholder for locations where you would like inference to occur:

constinstance=newFoo<_,string>(0,"");constresult=foo<_,string>(0,"");consttagged=tag<_,string>`tags ${12}${""}`;constjsx=<Component<_,string>x={12}y="" cb={props => void (props.x.toFixed() + props.y.toUpperCase())} />;

This allows users to override a variable in a list of defaulted ones without actually explicitly providing the rest or allow a type variable to be inferred from another provided one.

Implements #26242.
Supersedes #23696.

Fixes#20122.
Fixes#10571.

Technically, this prevents you from passing a type named _ as a type argument (we do not reserve _ in general and don't think we need to). Our suggested workaround is simply to rename or alias the type you wish to pass. Eg,

interface_{(): UnderscoreStatic;}foo<_>();// bad - triggers partial type inference, instead:typeUnderscore=_;foo<Underscore>();// good

we did a quick check over at big ts query, and didn't find any public projects which passed a type named _ as a type argument in an expression/inference position, so it seems like a relatively safe care-out to make.

Prior work for the _ sigil for partial inference includes flow and f#, so it should end up being pretty familiar.

[João Dias (alfaproject)]

Why write infer explicitly? Could we do like destructuring? <, string> instead of <infer, string>

By default, it would infer.

[Wesley Wigham (weswigham)]

João Dias (@alfaproject) I wrote my rationale down in #26242

[jwbay]

Would this PR enable this scenario? I didn't see a test quite like it. Basically extracting an inferred type parameter from a specified type parameter.

typeBox<T>={value: T};typeHasBoxedNumber=Box<number>;declarefunctionfoo<TextendsBox<S>,S>(arg: T): S;declareconsthbn: HasBoxedNumber;foo<HasBoxedNumber,infer>(hbn).toFixed();

[Wesley Wigham (weswigham)]

Based on the design meeting feedback, this has been swapped to variant 2 from the proposal - using the * sigil as a placeholder for inference. We'll need updates to our tmlanguage to get syntax highlighting right (although we already parsed * in type positions for jsdoc, so we probably should have already).

[Wesley Wigham (weswigham)]

Would this PR enable this scenario? I didn't see a test quite like it. Basically extracting an inferred type parameter from a specified type parameter.

As is, no. Other type parameters (supplied or no) are not currently inference sites for a type parameter. We could enable it here (just by performing some extra inferType calls between the supplied types and their parameters' constraints), probably, but... should we? Anders Hejlsberg (@ahejlsberg) you have an opinion here?

[Anders Hejlsberg (ahejlsberg)]

Anders Hejlsberg (@ahejlsberg) you have an opinion here?

I don't think we want constraints to be inference sites, at least not without some explicit indication. At some point we might consider allowing infer declarations in type parameter lists just as we do in conditional types:

typeUnbox<TextendsBox<infer U>>=U;

Though you can get pretty much the same effect with conditional types:

typeUnbox<TextendsBox<any>>=TextendsBox<infer U> ? U : never;

[Wesley Wigham (weswigham)]

Alright, I'll leave this as is then and just mention that it's available as a branch if we ever change our minds in the future.

[Trey Brisbane (treybrisbane)]

Wesley Wigham (@weswigham) It seems inconsistent (and kinda strange) to use the * sigil for this when we already use the infer keyword to denote explicit type inference...

typeTagged<Oextendsobject,T>=O&{__tag: T};// "Infer a type, and make it available under the alias 'T'"declarefunctiongetTag<OextendsTagged<any,any>>(object: O): OextendsTagged<any, infer T> ? T : never;// "Infer a type, and make it available to 'getTag' under the alias at the first type position"getTag<infer>({foo: string,__tag: 'bar'})// => 'bar'

This seems like an obvious syntactic duality to me... What was the reason you instead decided to go with *?

[Ryan Cavanaugh (RyanCavanaugh)]

The existing infer T keyword produces a new binding for T; this wouldn't be available in argument positions (e.g. you can't write getFoo<infer T, T>()). Having the infer keyword have arity 1 in conditional types and arity 0 in type argument positions seems like a decrease in overall consistency rather than an increase.

[KyleDavidE (KyleDavidE)]

It would probably be nice to be able to declare infer on the functions, ex: function foo<A, B = infer>(b: B, c: SomeComplexType<A,B>): SomeOtherComplexType<A,B>

[Trey Brisbane (treybrisbane)]

Ryan Cavanaugh (@RyanCavanaugh)

Having the infer keyword have arity 1 in conditional types and arity 0 in type argument positions seems like a decrease in overall consistency rather than an increase.

Thanks for the response. :)

Fair enough, but I'd argue that this decrease in consistency is far less than that of introducing an entirely new sigil for this purpose. Is there really a benefit to users in using such a radically different syntax for something whose only difference to infer T is the arity?

[Trey Brisbane (treybrisbane)]

Something else to consider is that TypeScript supports JSDoc, and * in JSDoc means any. I'm not sure it's a good idea to reuse a symbol that means any in one context for something that means "please infer this type for me" in another context.

If we're concerned about making operators/keywords context-sensitive, then again it seems like making infer context-sensitive is far less of an evil than doing the same for *.

[insidewhy]

I don't mind * as it jives with flow. Users of typescript can just avoid * in jsdoc and always use any for the purpose easily enough?

I'd also like to see this:

constinstance=newBlah<T,**>(1,'b',false,newDate())

I have a class that bundles many string literal types and I have to enumerate them all at every callsite even when I'm using the code from this branch. Everytime I add a new string literal I have to update every single callsite which is a massive drag ;)

[insidewhy]

Consider:

typeLiteralMap<S1extendsstring,S2extendsstring,S3extendsstring>={item1: S1,item2: S2,item3: S3}

With this feature at every definition using this type I have to use:

functionuser(map: LiteralMap<*,*,*>){}

Now if I need to add a new literal to my map I have to update this to:

typeLiteralMap<S1extendsstring,S2extendsstring,S3extendsstring,S4extendsstring>={item1: S1,item2: S2,item3: S3,item4: S4,}

which is no big deal, but now I also have to update every single use of this to:

functionuser(map: LiteralMap<*,*,*,*>){}

With LiteralMap<**> I can just update the definition without affecting every area it is used.

[Javier Gonzalez (xaviergonz)]

Or it could follow the tuple system

typeLiteralMap<S1?,S2?,S3?>={item1: S1,item2: S2,item3: S3}functionuser(map: LiteralMap){}// infer, infer, inferfunctionuser(map: LiteralMap<boolean>){}// boolean, infer, inferfunctionuser(map: LiteralMap<_,boolean>){}// infer, boolean, infertypeLiteralMap<S1,S2,S3?>={item1: S1,item2: S2,item3: S3}functionuser(map: LiteralMap){}// not allowed, S1 and S2 missingfunctionuser(map: LiteralMap<boolean>){}// not allowed, S2 missingfunctionuser(map: LiteralMap<_,boolean>){}// infer, boolean, infer

alternatively it could use the default assignation (which I guess makes more sense, since if you want it to infer the default type makes no sense?)

typeLiteralMap<S1=_,S2=_,S3=_>={item1: S1,item2: S2,item3: S3}functionuser(map: LiteralMap){}// infer, infer, inferfunctionuser(map: LiteralMap<boolean>){}// boolean, infer, inferfunctionuser(map: LiteralMap<*,boolean>){}// infer, boolean, infertypeLiteralMap<S1,S2,S3=_>={item1: S1,item2: S2,item3: S3}functionuser(map: LiteralMap){}// not allowed, S1 and S2 missingfunctionuser(map: LiteralMap<boolean>){}// not allowed, S2 missingfunctionuser(map: LiteralMap<_,boolean>){}// infer, boolean, infer

[Bazyli Brzóska (niieani)]

Much better than #23696. Great stuff 👍 Thanks!

[cevek]

Ryan Cavanaugh (@RyanCavanaugh) What the problem with this PR? Is this too complicated? I wait this feature more than 2 years. I really need this one in a lot of places. Currently I need to use dirty hacks like

functionx<A>(){return<B>(prop: {a: A,b: B})=>void}x<number>()({a:1,b:'b'})

[Mike Lysikov (d8corp)]

Can we split generic types by some symbol, like ";".
Before the splitter, generic types that can be provided from outside.
After the splitter, they are never be provided from outside.

declarefunctionfoo<// available outsideOextendsRecord<string,any>;// privateVextendsstring>(value: V): O&Record<'value',V>consttest=foo<{test: true}>('value')// test: { test: true } & { value: 'value' }

[Aleksey Bobyr (Alexsey)]

Can we split generic types by some symbol, like ";". Before the splitter, generic types that can be provided from outside. After the splitter, they are never be provided from outside.

declarefunctionfoo<// available outsideOextendsRecord<string,any>;// privateVextendsstring>(value: V): O&Record<'value',V>consttest=foo<{test: true}>('value')// test: { test: true } & { value: 'value' }

Considering that EcmaScript has introduced and TypeScript has adopted an ergonomic # to specify "private" fields in classes, I think it would be intuitive enough to use the same ergonomic approach to specify private type parameters:

declarefunctionfoo<OextendsRecord<string,any>,
#V extends string
>(value: #V): O&Record<'value', #V>consttest=foo<{test: true}>('value')// test: { test: true } & { value: 'value' }

[Nicky McCurdy (nickserv)]

I'd prefer if TypeScript didn't add non-standard features that look like private class fields, as it may increase usage of private class fields, which don't support certain libraries that rely on Proxies (including Vue).

Alternatively, we could support both # and the private keyword, like TypeScript already does in class declarations.

[Mike Lysikov (d8corp)]

Can we split generic types by some symbol, like ";". Before the splitter, generic types that can be provided from outside. After the splitter, they are never be provided from outside.

declarefunctionfoo<// available outsideOextendsRecord<string,any>;// privateVextendsstring>(value: V): O&Record<'value',V>consttest=foo<{test: true}>('value')// test: { test: true } & { value: 'value' }

Considering that EcmaScript has introduced and TypeScript has adopted an ergonomic # to specify "private" fields in classes, I think it would be intuitive enough to use the same ergonomic approach to specify private type parameters:

declarefunctionfoo<OextendsRecord<string,any>,
#V extends string
>(value: #V): O&Record<'value', #V>consttest=foo<{test: true}>('value')// test: { test: true } & { value: 'value' }

Looks qualified to me. I suggested ";" like in "for i" loop syntax. Any way, there are no cases to mix private and public types.

I'm not sure about

declarefunctionfoo<
#V extends string,OextendsRecord<string, #V>>(value: #V): O&Record<'value', #V>consttest=foo<{test: true}>('value')// test: { test: true } & { value: 'value' }

[Stephen Hicks (shicks)]

This discussion of private generic parameters is getting a bit off-topic to this issue (though as I asserted above, it's tangentially relevant insofar as the syntax should work well together). I am very interested in continuing the private types discussion, but I think it's more appropriate on #42388 so I've moved the discussion there.

As far as this specific issue goes, I'm definitely in favor, don't particularly care about _ vs infer, and would love to see the follow-up of definition-site partial inference happen sooner rather than later.

[Roi Kingon (mr-rpl)]

any updates here? would love the ability to partially supply generics while the remainder continue to infer

[Anton Bessonov (Bessonov)]

Coming from this issue: #19205 . It would be nice if the inference wouldn't be turned off.

[Debove Christopher (ChibiBlasphem)]

Any news on this topic? Following the issue for years. It would be great to have insight on whether this is approved or not. Seeing the comments here this feature seems quite demanded. How it's done is another thing.

[Martin Johns (MartinJohns)]

Debove Christopher (@ChibiBlasphem) Please read https://github.com/microsoft/TypeScript/wiki/FAQ#any-updates.

[Nathan Shively-Sanders (sandersn)]

All the recent activity on this PR has been design discussion. I think we should close this and go back to design to get something workable there.

[TypeScript Bot (typescript-bot)]

With 6.0 out as the final release vehicle for this codebase, we're closing all PRs that don't fit the merge criteria for post-6.0 patches. If you think this was a mistake and this PR fits the post-6.0 patch criteria, please post to the 6.0 iteration issue with details (specifically, which PR and which patch criteria it satisfies).

Next steps for PRs:

• For crash bug fixes or language service improvements, PRs are currently accepted at the typescript-go repo
• Changes to type system behavior should wait until after 7.0, at which point mainline TypeScript development will resume in this repository in the Go codebase
• Library file updates (lib.d.ts etc) continue to live in this repo or the DOM Generator repo as appropriate