BUG: Generic type inference failure

[pmunin]

TypeScript Version: 2.5.3 / nightly (2.5.0-dev.201xxxxx)

Code (gist)

type MyArgs = {
    prop1:any;
    prop2?:any;
}

interface IArgsHandler<TArgs extends MyArgs>
{
    handle(args:TArgs):void;
}

function MyFunc<TMyArgs extends MyArgs>(args:TMyArgs, ...handlers:IArgsHandler<TMyArgs>[])
{
    for(let handler of handlers||[])
    {
        handler.handle(args);
    }
}


function exampleOfIssue()
{
    MyFunc({prop1:123, newProp:"asdasd"},{
        handle(a){
            if(a.prop2) //Compilation error here: error TS2551: Property 'prop2' does not exist on type '{ prop1: number; newProp: string; }'. Did you mean 'prop1'?
            {
                console.log("There is prop2");
            }
        }
    })
}

Expected behavior:
Compilation successfull, because TMyArgs extends MyArgs, which has prop2.

Actual behavior:

Compilation error here: error TS2551: Property 'prop2' does not exist on type '{ prop1: number; newProp: string; }'. Did you mean 'prop1'?

[olegdunkan]

Typscript infers that TMyArgs in MyFunc parameter has {prop1:number, newProp:string} type.
{prop1:number, newProp:string} is valid (compatible) type for the constraint type MyArgs = {prop1:any; prop2?:any;}.

[pmunin]

@olegdunkan incorrect - look at the code carefully, both MyFunc's and IArgsHandler's TMyArgs has a constraint - must be extended from MyArgs. So whatever args come as an input for both of them must be have all MyArgs's props.

[olegdunkan]

When you write this:

MyFunc({prop1:123, newProp:"asdasd"},{
        handle(a){
            if(a.prop2) //Compilation error here: error TS2551: Property 'prop2' does not exist on type '{ prop1: number; newProp: string; }'. Did you mean 'prop1'?
            {
                console.log("There is prop2");
            }
        }
    })

tsc checks call expression and tries to infer type for TMyArgs parameter, tsc sees TMyArgs in two positions first as a type for the args parameter, second in the rest parameter. Tsc infers for TMyArgs {prop1:number, newProp:string} type. It is assignable type to type MyArgs = { prop1:any; prop2?:any;}, but not the same, that is why you can't access to prop2 in instantiated MyFunc.
Every time you call MyFunc tsc instantiates MyFunc (for the checking purposes) with inferred type arguments for that call.
The more interesting question is how types are related to each other in different contexts.
For example, in your case if extends clause supposes the subtype relation TArgs to MyArgs then it will be error #1795, but it is not, because extends clause supposes an assignable relation and doesn't requires the optional member prop2 in MyArgs for types substituted with TArgs.

Edited
Spec stated:
For purposes of determining type relationships (section 3.11), type parameters appear to be subtypes of their base constraint.
But in the case of type inference we see that tsc uses assignment compatibility relationship.

[olegdunkan]

This code rises runtime error, but is the valid code in typescript.

type A = {
    x: number;
    y?: string;
}

class B<T extends A> {
    a: T;
    constructor(x:T) {
        this.a = x;
    }
    f() {
        return this.a.y!.charAt;        
    }
}


function f<T extends A>(a: T, b:B<T> = new B(a)) {
    b.f();
}

f({ x: 1, some: "" });

For optional members typescript has ! operator that can help us to write code above.

[aluanhaddad]

@olegdunkan that's true but it should not be used often and in this case as you point out a runtime error results.

Instead writing

return this.a.y && this.a.y.charAt;

will equally satisfy the type checker, and won't explode.

[pmunin]

@olegdunkan thanks for your efforts to explain - it's nice to know what's happening behind the scene in tsc, but it does not really matter for a user (developer), who expects generic constraints to work (like it works in other languages e.g. C#). Current behavior of tsc basically just ignores generic constraint, for the specified case - i.e. it does not matter if I write: IArgsHandler<TArgs extends MyArgs> or IArgsHandler<TArgs> - result is the same, which is confusing. And I create this bug to bring TS team's attention to this, and let them know that this behavior is at least confusing and not consistent.

[ahejlsberg]

This is working as intended. Type parameter constraints play no role in type inference, they are merely bounds that are checked after type inference completes. That aside, TypeScript is being accurate here--it inferred type {prop1:number, newProp:string} for TMyArgs which is the actual type of the argument, and since you stated that the callback parameter is also of type TMyArgs, it is correct to point out that there is no prop2 property. If you want additional optional parameters to be present in the callback argument, you can use an intersection type to add them:

function MyFunc<TMyArgs extends MyArgs>(args: TMyArgs, ...handlers: IArgsHandler<TMyArgs & MyArgs>[])
{
    // ...
}

This causes the example to behave as you intended.

[pmunin]

It is still confusing, how type parameter constraint is ignored by type inference, but thanks for workaround - it works.

[mhegazy]

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