Type definition: Adding type argument breaks type inferrence

[stelcheck]

TypeScript Version: 2.3.2

Code

Ref: mage/mage#42

Given the following type definition: https://github.com/stelcheck/mage/blob/5b5f116f1d09f93b54f089a11aa43f841cf1aa05/types.d.ts

By adding the type argument to the IState interface, state is no longer inferred.

// A *self-contained* demonstration of the problem follows...
import * as mage from 'mage'

export = <mage.core.IUserCommand> {
    acl: ['*'],
    execute: async function(state /* will complain that state is of type any */) {
        console.log(state)
        return 'ok'
    }
}

Expected behavior:

The type of state should be inferred to mage.core.IState

Actual behavior:

The type of state must now be explicitly stated.

[mhegazy]

The only place the new type parameter is referenced is in a return type, and return types are not inference position. #11152 tracks changing that.

[stelcheck]

My issue is actually not with the return type (which is correctly inferred in this case anyway - so a bit surprised to read that's currently an issue?); my issue is that as soon as I add a type parameter, the state variable is no longer inferred.

For instance, I still have the same issue if the type definition is as follow:

interface IUserCommand {
    acl?: string[];
    execute<T>(state: IState, second: T, ...args: any[]): any;
}

Or even as follow (spoecifying a type variable but not using it, and stripping all parts irrelevant to the issue being reported here):

interface IUserCommand {
    execute<T>(state: IState): any;
}

In all those cases the state parameter loose its inferrence (even though the very interface causing issue explicitly specifies the state of the first parameter). As soon as I remove the type parameter, state gets inferred as IState as expected.

[mhegazy]

My issue is actually not with the return type (which is correctly inferred in this case anyway - so a bit surprised to read that's currently an issue?); my issue is that as soon as I add a type parameter, the state variable is no longer inferred.

In the .d.ts file linked in the OP, the function definition is:

        interface IUserCommand {
            acl?: string[];
            execute<T>(state: IState, ...args: any[]): Promise<T>;
        }

see https://github.com/stelcheck/mage/blob/5b5f116f1d09f93b54f089a11aa43f841cf1aa05/types.d.ts#L1365

[mhegazy]

For instance, I still have the same issue if the type definition is as follow:

interface IUserCommand {
    acl?: string[];
    execute<T>(state: IState, second: T, ...args: any[]): any;
}

Generic signatures are not used as a contextual type. When you did not have a type parameter, the type of the signature was used to contextually type async function(state /* will complain that state is of type any */) { and state had a type. when you added the T, that stopped, and thus state had the type any.

related to #9366

[stelcheck]

Thank you for the explanation, much appreciated.

I see however that in the following case, the parameter's type is properly inferred:

type MyFunction<T> = (val: T) => string

const func = <MyFunction<number>> function (val) {
  return val.toString()
}

It appears that while generic interfaces do not properly carry the inferrence, types do. Just so that I may better understand the inferrence system as it exists today, would you be able to explain why types are treated differently from interfaces in this case?

Edit: In this particular case, to make it work with the code part of the original report, I had to externalise the type definition of the attribute, and explicitly type the attribute thereafter - simply changing the interface into a type didn't work:

import * as mage from 'mage'

type ExecuteMethod<T> = (state: mage.core.IState, ...args: any[]) => Promise<T>;

type UserCommand<T> = {
    acl?: string[],
    execute: ExecuteMethod<T>
}

export = <UserCommand<string>> {
  acl: ['*'],
  execute: async function (state) {
    console.log('sample.sample state', state)
    return 'hello world'
  }
}

In this example, simply turning UserCommand into an IUserCommand interface would bring back the problem once again.

[mhegazy]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.