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

By default, it would infer.

@alfaproject I wrote my rationale down in #26242

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.

type Box<T> = { value: T };

type HasBoxedNumber = Box<number>;

declare function foo<T extends Box<S>, S>(arg: T): S;

declare const hbn: HasBoxedNumber;

foo<HasBoxedNumber, infer>(hbn).toFixed();

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

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? @ahejlsberg you have an opinion here?

@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:

type Unbox<T extends Box<infer U>> = U;

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

type Unbox<T extends Box<any>> = T extends Box<infer U> ? U : never;

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.

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

type Tagged<O extends object, T> = O & { __tag: T };

// "Infer a type, and make it available under the alias 'T'"
declare function getTag<O extends Tagged<any, any>>(object: O): O extends Tagged<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 *?

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.

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>

@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?

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

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:

const instance = new Blah<T, **>(1, 'b', false, new Date())

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 ;)

Consider:

type LiteralMap<S1 extends string, S2 extends string, S3 extends string> = {
  item1: S1,
  item2: S2,
  item3: S3
}

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

function user(map: LiteralMap<*, *, *>) {}

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

type LiteralMap<S1 extends string, S2 extends string, S3 extends string, S4 extends string> = {
  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:

function user(map: LiteralMap<*, *, *, *>) {}

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

Or it could follow the tuple system

type LiteralMap<S1?, S2?, S3?> = {
  item1: S1,
  item2: S2,
  item3: S3
}

function user(map: LiteralMap) {} // infer, infer, infer
function user(map: LiteralMap<boolean>) {} // boolean, infer, infer
function user(map: LiteralMap<_, boolean>) {} // infer, boolean, infer

type LiteralMap<S1, S2, S3?> = {
  item1: S1,
  item2: S2,
  item3: S3
}

function user(map: LiteralMap) {} // not allowed, S1 and S2 missing
function user(map: LiteralMap<boolean>) {} // not allowed, S2 missing
function user(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?)

type LiteralMap<S1 = _, S2 = _, S3 = _> = {
  item1: S1,
  item2: S2,
  item3: S3
}

function user(map: LiteralMap) {} // infer, infer, infer
function user(map: LiteralMap<boolean>) {} // boolean, infer, infer
function user(map: LiteralMap<*, boolean>) {} // infer, boolean, infer

type LiteralMap<S1, S2, S3 = _> = {
  item1: S1,
  item2: S2,
  item3: S3
}

function user(map: LiteralMap) {} // not allowed, S1 and S2 missing
function user(map: LiteralMap<boolean>) {} // not allowed, S2 missing
function user(map: LiteralMap<_, boolean>) {} // infer, boolean, infer

What's blocking this from being merged right now?

This will be useful in making mixin class definitions more terse!

function AwesomeMixin<T extends Constructor>(Base: T) {
    // This would be nice, a properly typed mixin all in a single return statement.
    // Pretend the second arg in the following MixinResult application is inferred:
    return MixinResult<T>(class Awesome extends Constructor(Base) {
        // ...
    })
}

type Constructor<T = object, A extends any[] = any[]> = new (...a: A) => T

function Constructor<T = object, Static = {}>(Ctor: Constructor<any>) {
    return (Ctor as unknown) as Constructor<T> & Static
}

function MixinResult<TBase extends Constructor, TClass extends Constructor = Constructor>(Class: TClass) {
    return Class as Constructor<InstanceType<TClass> & InstanceType<TBase>> & TClass & TBase
}

// a mixin for use on Custom Elements, and composed of multiple mixins:
function AwesomeMixin<T extends Constructor<HTMLElement>>(Base: T) {
    // Pretend the second arg in the following MixinResult application is inferred:
    return MixinResult<T>(class Awesome extends Mixin1(Mixin2(Constructor<HTMLElement>(Base))) {
        // ... inside here, we get all types from Mixin1, Nixin2, and HTMLElement ...
    })
}

function AwesomeMixin<T extends Constructor<HTMLElement>>(Base: T) {
    class Awesome extends Mixin1(Mixin2(Constructor<HTMLElement>(Base))) {
        // ...
    }
    // less terse, more duplication of the Awesome identifier
    return Awesome as MixinResult<typeof Awesome, T>
}


// ... the other parts omitted ... and MixinResult is only a type, not a function:
type MixinResult<TClass extends Constructor, TBase extends Constructor> =
    Constructor<InstanceType<TClass> & InstanceType<TBase>> & TClass & TBase

function AwesomeMixin<T extends Constructor<HTMLElement>>(Base: T) {
    class Awesome extends Mixin1(Mixin2(Constructor<HTMLElement>(Base))) {
        // ...
    }
    // better, one less "Awesome" identifier than the previous example
    return MixinResult<T>(Awesome)
}

// ... other stuff omitted ... but MixinResult is a function again:
function MixinResult<TBase extends Constructor, TClass extends Constructor = Constructor>(Class: TClass) {
    return Class as Constructor<InstanceType<TClass> & InstanceType<TBase>> & TClass & TBase
}

Currently it's most expected feature in TypeScript for me 😵

I really need this feature right now.

Could this support a scenario where the inference of a generic parameter would be the default behavior?

I'm thinking of something like this:

function f<P = never, T extends string = _>(type: T) {}

This would be useful for Redux action creators.

It would allow us to have an optional generic parameter but still have type infered as a string literal type. Then we could have a conditional redurn type that would depend on P being never or something else.

Just adding some design thoughts :)

Use the infer keyword over _ underscore or * asterisk

I really think this would be a good choice for the following reasons:

1. It's more understandable at-a-glance. A new TS developer can guess what it's doing from a plain reading, whereas they'd definitely have to Google for documentation on _ underscore (and it's hard to Google punctuation). While * asterisk is better I still think the first thought most devs would have is that it's an alternate for any. Using infer doesn't have this problem.

2. Fewer special characters. TS already looks a bit scrappy with lots of brackets and punctuation going on. Consider how much cleaner the myVar as string is than using <string>myVar

3. Less future confusion. You can imagine an asterisk or underscore being used in JavaScript in the next five years to mean something else (e.g. private properties?) which could end up being confusing.

Use infer as default type in generic declaration

@KyleDavidE suggested something above that I loved, and that goes great with this thread: being able set the default value of a generic to infer, so you can partially specify generics without having to fill infer from the right too when you're using the type.

It would look something like this:

function getName<A, B = infer>(a: A, b: B): B {}

const abc: boolean = getName<string>("abc", true);

@Nandiin If you modify your first workaround example a bit, the end usage isn't really all that bad. You still have multiple parentheses, but at least the generic parameters aren't awkwardly sandwiched between them:

type Modified<O, K extends string, T> = O & Record<K, (v: T) => void> \n
declare function modify<T>(): <O, K extends string>(target: O, k: K) => Modified<O, K, T>
const John = {}
const modified = modify<number>()(John, 'age')
modified.age // (v: number) => void
modified.age(18)`

@weswigham You are incredible, great work!

I'm patiently waiting for this merge.
Currently I'm using the currying workaround which I'd very much like to stop using.

Is there any ETA on this merge ?

Yeah... currying looks so dirty... hope this PR could be merged soon...

Like @dhoulb's idea on using the infer keyword for inferring a type. Just a slight modification suggestion:

type TypeConstraint = string | boolean;
function getName<A, infer B extends TypeConstraint>(a: A, b: B): B {}

// ok
const abc: boolean = getName<string>("abc", true);
const abc: boolean = getName<string, boolean>("abc", true);

// error
const abc: boolean = getName<string>("abc", 10);

Should someone overtake this? I see last changes in 2018, but this feature would be really cool

This is not stalled for lack of ownership, rather, for lack of drive to accept the feature in the first place.

I see, sad sad, I would vote for <infer, string> or <, string>, but _ looks strange IMO.

This is not stalled for lack of ownership, rather, for lack of drive to accept the feature in the first place.

@DanielRosenwasser @ahejlsberg @RyanCavanaugh @andy-ms as the reviewers on this PR, can you provide an update as to why this PR isn't being accepted? There seems to a lot of interest from the community in this feature.

The sad thing about this is it's a problem I hit with almost every typescript project I work on.

And the only way around it is to add an extra function. So in turn my APIs stop making sense (especially for javascript consumers) because now people have to use doStuff(1)(2, 3) when they should just be able to use doStuff(1, 2, 3).

I thought this would be accepted in the near future as it was added to the roadmap.
But this is no progress... Why not merge?

https://github.com/microsoft/TypeScript/wiki/Roadmap

@weswigham Maybe the better way is to implement this proposal?

If you pass the first type parameter to myLookerUpper2 function, the second type parameter will be automatically inferred as default type assigned to it — keyof T. To improve type inference we can use default types only in cases when type parameter can't be inferred another way. So, it means that in case of this function

declare function myLookerUpper2<T, K extends keyof T = keyof T>(t: K): T[K]

function parameter t should have higher priority to infer type parameter K than default type parameter value keyof T

Then we will be available to move all type parameters that should be inferred automatically to the end of the list and assign them all default values.

This approach has some pros:

1. No need to add all that over-engineering with placeholders.
2. Developer can choose by his own the default type for the case if type parameter can't be inferred automatically.
3. Simple to implement (I guess)

@awerlogus but there will still be a case of someone wanting to specify a specific type arg in the middle of the inferrable parameters. That proposal I don't think covers that case like this one does.

I also like infer better. The docs need to clearly explain the arity differences depending on usage site.

Plus I think it makes things like the following more sensible and inline with familiar patterns:

Instead of

const instance = new Blah<T, **>(1, 'b', false, new Date())

we can write

const instance = new Blah<T, ...infer>(1, 'b', false, new Date())

But arguably with trailing parameters that should just be

const instance = new Blah<T>(1, 'b', false, new Date())

but the only bad thing is that it may be a breaking change. :/ In that case, ...infer is inline with familiar patterns.

For non-trailing args, to avoid writing infer many times, what about something like

const instance = new Blah<infer * 2, T, infer>(1, 'b', false, new Date())

where the *2 spreads the infer across two parameters?

I was looking for this functionality in TypeScript as well and I spent a few hours trying to get this working. During my exploration I naturally discovered the infer and leading comma syntaxes:

type S = {
  someProperty: string;
};

// infer syntax
function f1<T = never, U extends keyof S = infer>(param: U): U | T {
  return param;
}

const a1 = f1<boolean>('someProperty');

// leading comma syntax
function f2<U extends keyof S, T = never>(param: U): U | T {
  return param;
}

const b1 = f2<, boolean>('someProperty');

Although I'd be tickled pink if this PR got merged with the current syntax, I would prefer one of these alternative syntaxes. They have both been proposed already in this thread and I think it is worth noting that I discovered them both naturally before even seeing the proposals. On the other hand, I did not naturally discover the underscore syntax which is currently the syntax of the PR. To me that says that the underscore syntax should be replaced with one of the other two, but that's just my two cents. If I could choose, I would choose the infer syntax over the others.

It would be great to see this merged, no matter what syntax is used.

Also bumping this, would love the keyword "infer". Seems clean and verbose.

This is... interesting. If it's for compatibility concerns can't we just set a new compiler flag on this and get on with it?