You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In your example, there isn't really a type to bind to. You're saying T extends a known type, but there's not enough information to know which resulting type. It's like saying "pick a subtype of { "0": (p1: number) => number }, but I won't tell you which one".
The x=>x isn't enough to help figure it out either.
When the compiler hits that point, it chooses a conservative answer, like {}, to help prevent other errors from slipping through.
And one more question. If we have a tuple as a result, then we have a contextual type with a property "0" for our array literal. But at the same time, we don't have a contextual type for array element. How could it be?
This isn't specific to tuples. You see the same behavior with object literals:
functionf<Textends{q: (p1: number)=>number}>(p: T): T{returnp;}varv=f({q: x=>x});// v is typed as [{}]. Expected [number=>number]
We don't meaningfully contextually type x => x because the parameter type is just T. Arguably we should use base constraint of a type parameter when contextually typing by it, which should make all these examples "just work". Anders Hejlsberg (@ahejlsberg) ?
Ryan Cavanaugh (@RyanCavanaugh) Well, at least there should be an compilation error, because [{}] is not assignable to { "0": (p1: number) => number }. Because of this IMHO this is a bug.
Ok, turns out we are leaking an internal compiler type that looks like {}. It happens whenever you try to infer a type for a type parameter, and the type parameter contains the anyFunctionType, but isn't directly the anyFunctionType.
Activity
sophiajt commentedon Jul 21, 2015
In your example, there isn't really a type to bind to. You're saying T extends a known type, but there's not enough information to know which resulting type. It's like saying "pick a subtype of { "0": (p1: number) => number }, but I won't tell you which one".
The x=>x isn't enough to help figure it out either.
When the compiler hits that point, it chooses a conservative answer, like {}, to help prevent other errors from slipping through.
osdm commentedon Jul 21, 2015
jonathandturner Could you please point to paragraph in the specification which discusses this process of choosing a conservative answer?
osdm commentedon Jul 21, 2015
And one more question. If we have a tuple as a result, then we have a contextual type with a property "0" for our array literal. But at the same time, we don't have a contextual type for array element. How could it be?
RyanCavanaugh commentedon Jul 21, 2015
This isn't specific to tuples. You see the same behavior with object literals:
We don't meaningfully contextually type
x => xbecause the parameter type is justT. Arguably we should use base constraint of a type parameter when contextually typing by it, which should make all these examples "just work". Anders Hejlsberg (@ahejlsberg) ?osdm commentedon Jul 21, 2015
Ryan Cavanaugh (@RyanCavanaugh) Well, at least there should be an compilation error, because [{}] is not assignable to { "0": (p1: number) => number }. Because of this IMHO this is a bug.
RyanCavanaugh commentedon Jul 21, 2015
That's a good point
JsonFreeman commentedon Jul 21, 2015
I'm debugging this now. I'll be able to give you an answer soon about what is going on.
JsonFreeman commentedon Jul 21, 2015
jonathandturner Ryan Cavanaugh (@RyanCavanaugh) Dmitry Osinovskiy (@osdm) We do use the base constraint for contextual typing, as of recently, #3822. So there is something else amiss.
JsonFreeman commentedon Jul 21, 2015
Ok, turns out we are leaking an internal compiler type that looks like
{}. It happens whenever you try to infer a type for a type parameter, and the type parameter contains the anyFunctionType, but isn't directly the anyFunctionType.JsonFreeman commentedon Jul 21, 2015
I am adding a rule in the subtype relation to fix this.
JsonFreeman commentedon Jul 21, 2015
Ok, the new rule is that a type with signatures is not a subtype of the anyFunctionType. It is assignable, but it's not a subtype.