Repository navigation
T[keyof T] assignable to T[K] #17166
Description
TypeScript Version: 2.4.0 / nightly (2.5.0-dev.201xxxxx)
Code
// A *self-contained* demonstration of the problem follows...
function f<T, K extends keyof T>(obj: T, k: K, value:T[K]) {
for (let key in obj) {
value = obj[key];
break;
}
return value;
}
f({ x: 1, y: "" }, 'y', "1").charAt(0); //runtime errorExpected behavior:
Compiler error
Actual behavior:
Runtime error
Activity
jcalz commentedon Jul 13, 2017
It looks like TS is interpreting
T[K]whereK extends keyof Tto be something likeT[keyof T], i.e., the union of all values of properties ofT. And so it allows any value assignable toT[keyof T]to a variable of typeT[K], even when that could lead to runtime errors.Another instance of this:
I doubt this is intended. It seems like a design limitation, if not a bug.
olegdunkan commentedon Jul 13, 2017
Joe Calzaretta (@jcalz) I am also in doubt about this, because there is no specification for this case all I can is to pretend it to be a bug)
But my thoughts about this case are other.
TypeScript can infer type for
valueasstring, but type ofobj[key]maybe union of allT[K]types therefore we can't assign union of type to it's constituent. But it is a assumption.[-]Lookup type inside "for in" loop[/-][+]T[keyof T] assignable to T[K][/+]sandersn commentedon Aug 28, 2017
olegdunkan the fix for your bug is up at #17912.
Joe Calzaretta (@jcalz) your repro exposes a design limitation; if we distinguished the types of read locations and write locations then we could say that the type of
Foo[K]isstring | numberwhen reading andstring & numberwhen writing.However, read/write distinction is similar to variance handling, so we are unlikely to add one set of features without the other. And that set of features is very complex, both to use and to implement, so I don't think it will happen soon, if at all.