Repository navigation
Unexpected behavior of generic constraints #3410
Description
Activity
Pinging Jason Freeman (@JsonFreeman)
Our assignability relation ignores generics and constraints in signatures. It just replaces all type parameters with
any.I will add that we ignore generics because we believe taking them into account will be slow. And in general it leads to never-ending recursion if the signature was in a generic type. Because of this it seems not worth it.
I understand the reasons to not enforce this, but why allow it in the first place?
why allow it in the first place?
Can you clarify? We "allow" it because we don't do the computation that would tell us whether or not the code might be an error. Given a lack of answer, we can't simply disallow all uses of generics.
Sure. If I understood correctly, generic constraints are replaced with
any(as per Jason Freeman (@JsonFreeman) comment above). So given these three cases:// fails function foo<T extends { someNumber: number }>(thingWithNumber: T): number { return thingWithNumber.someNumber; } [1, 2].map(foo); // also fails. interface WithNumber { someNumber: number; } function bar <T extends WithNumber> (thingWithNumber: T): number { return thingWithNumber.someNumber; } [1, 2].map(bar); // works. function baz(thingWithNumber: WithNumber): number { return thingWithNumber.someNumber; } [1, 2].map(baz); // compile error
Only the latter works. Seems to me that the
<T extends SomeType>should be disallowed, since it does not enforce the type constraint and gives you a false sensation of safety.Constraints still provide many errors:
interface Foo { x: number; } interface Bar { y: string; } function myFunc<T extends Foo>(a: T): T { console.log(a.x); // OK console.log(a.y); // Error return a; } var f: Foo, b: Bar; myFunc(f); // OK myFunc(b); // Error
Oh, okay, so what are the cases where those constraints are not enforced? I could do this in your example:
[b].map(myFunc)is it only when passing
myFuncaround?When you call a function with a constrained type parameter, that function's type parameter constraint is checked. When you pass a function with a type parameter constraint, the constraint is not checked.
May we revisit the current behaviour? I believe another incarnation of this issue is: #12970.
Yes, both issues share the theme of type parameters being erased for signature comparison.
Jason Freeman (@JsonFreeman) I've gone into the type checker and simply disabled the condition that asserts for non-genericity of call signatures before allowing their use in contextual typing (can't link to it because
checker.tsis too large for Github now, but it's on line 12784 in master @ commit af64ef8). You can see the branch here: https://github.com/Microsoft/TypeScript/compare/master...masaeedu:contextuallytypegenerics?expand=1This only affects inferred types within the function expression you're assigning/passing, and nowhere else, so I think it is unlikely to have far-reaching effects. Aside from 7 testcases that are deliberately asserting looser inference than can be gleaned, all tests pass, and the use-case I've described in #15016 starts working.
Can you think of cases where this would break, or where performance would be significantly degraded? I'm not sure if there's a performance test suite, but anecdotally, working on the compiler codebase itself doesn't seem any slower.
Asad Saeeduddin (@masaeedu) As I recall, there are two separate, but related issues here. One is the refusal to use a generic signature to contextually type a function expression. That is what you've changed. The second issue is that when two signatures are compared for assignability, their type parameters are erased to
any, which happens after contextual typing. It is this second behavior that's motivated by fear of slowness, or infinite recursion. So changing the contextual typing rules does not seem likely to impact these concerns.In terms of semantic consequences, two things come to mind. One is that in general, the effects of contextual typing might not be as local as you might think. If you are passing a function expression as an argument to an overloaded function, the way that argument is contextually typed could affect which overload is selected, if it changes the argument's compatibility with particular overloads. This could be something to investigate.
The second question has to do with the function instantiateTypeWithSingleGenericCallSignature in checker.ts. The intent is to flow types by instantiating generic functions in certain situations. Here's an example:
declare function foo<T>(x: T): T; declare function applyFn<T, U>(arg: T, fn: (x: T) => U): U; applyFn(0, foo); // Returns number
The contextual signature supplied by
fnis not generic in this example. With your change, I'd expect the types to flow even iffnis generic, if the example were something like:declare function applyFn<T, U>(arg: T, fn: <V extends T>(x: V) => U): U;
Reacted by Asad Saeeduddinrelated to #5616
I've put up a PR (#16104) fixing this issue. The observation is that after the inference pass, the inferred signature is type checked separately. In that second, type checking phase, all generic arguments are being erased. However, the type parameters of the signature have already been fixed and we can do better by inferring the arguments against them. The proposed logic will still be correct if proper polymorphic unifications gets implemented, because even if there is an infinite substitution, it will be caught while inferring the signature, i.e. at the type checking step the inference will always be between a generic and a non-generic type.
- locked and limited conversation to collaborators
on Jun 19, 2018
The following code snippet compiles without type errors though the type variable
Tis constrained tostringtype.Non generic version
nonGenericBarworks as expected.Of course,
genericBarfunction is useless because constraining a type variable to a primitive type can be replaced by a non generic function likenonGenericBar. However, the behaviour is somewhat unexpected and inconsistent.