Generic lambda identity function can cheat typesystem easily #8397

Activity

1. malibuzios commented on Apr 30, 2016

   

   malibuzios

   on Apr 30, 2016

   Last edited by malibuzios

   More actions

   (I'm using version 1.9.0-dev.20160429)

   Hi, I tried to rewrite the example a bit differently:

   This errors:

   let func: <T>(a: T): T => "abcd"; // error: string is not assignable to T

   However when the signature is declared separately, as a type. This invalid return type can be 'hidden' under the declared type, as the call signature type <T>(a: T) => string is allowed to be assigned to the call signature type <T>(a: T) => T:

   type Func = <T>(a : T) => T;
   
   let func: Func = <T>(a: T): string => "abcd"; // no error

   And then a caller can use any type for T and the compiler would still consider the return type to be T and not string:

   let x = func(1234); // 'x' gets type 'number' but the actual value "abcd".

   It looks as if the compiler considers these function types compatible, in particular the return type string is seen to be assignable to T.

   I'll try to isolate and rewrite it as clearly as possible:

   type Func1 = <T>(a: T) => T;
   type Func2 = <T>(a: T) => string;
   
   let func1: Func1;
   let func2: Func2;
   
   func1 = func2; // no error

   And compare it to:

   type Func1 = <T>(a: T) => number;
   type Func2 = <T>(a: T) => string;
   
   let func1: Func1;
   let func2: Func2;
   
   func1 = func2; // error: type 'string' is not assignable to 'number'

   I'm aware that function parameters are bivariant, and based on my tests function return types should be covariant. I'm not sure if that has anything to do with this though. There isn't much further information I can provide at this point.
2. malibuzios commented on Apr 30, 2016

   

   malibuzios

   on Apr 30, 2016

   Last edited by malibuzios

   More actions

   Further investigation:

   #3410 includes some information (although almost a year old), explaining this check (or a related one, I'm not sure) is avoided to due performance reasons.
   #5616 is very similar to this (though the example there shows the return type assignment in the other direction), and seems to be 'In Discussion'.

   Seems like almost any function can be assigned from or to a generic signature. Parameters and the return type are considered to be of type any, so they will even accept void:

   declare let func1: <T, V>(a: T, b: V, c: V) => T;
   declare let func2: (a: number, b: string, c: void) => void;
   
   func1 = func2; // no error
3. iskiselev commented on Jun 16, 2016

   

   Igor Kiselev (iskiselev)

   on Jun 16, 2016

   More actions

   I'm not sure, if this should be looked in this issue, but currently TypeScript also doesn't look on generic type constraints when it check functions types:

   let f1: (input:number)=>{field:number};
   let f2: (input:number)=>{field:string};
   
   f1 = f2; // Type is not assignable error
   f2 = f1; // Type is not assignable error
   
   let gf1: <T extends {field:number}>(input:number)=>T;
   let gf2: <T extends {field:string}>(input:number)=>T;
   
   gf1 = gf2; // No error here, but should be.
   gf2 = gf1; // No error here, but should be.
   
4. Ryan Cavanaugh (RyanCavanaugh)

   added

   Design LimitationConstraints of the existing architecture prevent this from being fixedConstraints of the existing architecture prevent this from being fixed

   on Aug 18, 2016
5. RyanCavanaugh commented on Aug 18, 2016

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Aug 18, 2016

   Member

   More actions

   Unfortunately signatures are seen in their "erased" form (with type parameters replaced with their constraints) during assignability checks. This is something we're aware of as a hole but don't yet have a solution that gives satisfactory performance,
6. Ryan Cavanaugh (RyanCavanaugh)

   closed this as completedon Aug 18, 2016
7. zpdDG4gta8XKpMCd commented on Dec 20, 2016

   

   ZpdDG4gta (zpdDG4gta8XKpMCd)

   on Dec 20, 2016

   More actions

   Ryan Cavanaugh (@RyanCavanaugh) if performance is a problem (presumably due to recursive deep dives) why not limit checks to a certain depth that can be configured from tsconfig.json, who don't care about typesafety sets "depth: 0" and production ready builds "depth: 100"?

   👍React with 👍1Reacted by SlurpTheo
8. mhegazy commented on May 18, 2017

   

   Mohamed Hegazy (mhegazy)

   on May 18, 2017

   Contributor

   More actions

   tracked by #5616
9. microsoft

   locked and limited conversation to collaborators on Jun 19, 2018