Repository navigation
Type assertion only works if one type is completely assignable to the other #1447
Description
interface Foo {
a?: string;
b: string;
}
<Foo>{ a: undefined } // Neither type is assignable to the otherThis happens because with respect to property a, Foo is the winner, but with respect to property b, the object literal is the winner (because b is missing). I think what the user expects is for us to mix and match the direction of assignability at all levels of nesting. So if each property is assignable in either direction, the check passes for that property. If the check passes for all the properties, the type assertion is allowed.
This would require work in the spec to add a new symmetric relation "is assignable to or from", which applies itself appropriately to nested types and other nested constructs.
Activity
JsonFreeman commentedon Dec 11, 2014
Another potential fix is to copy optional properties into an object literal during contextual typing if they are missing.
ahejlsberg commentedon Dec 13, 2014
The right solution here is probably a new "is assignable to or from" relation as you suggest.
JsonFreeman commentedon Mar 23, 2015
Per issue #2441, we can use this for equality comparisons too.
JsonFreeman commentedon Jul 3, 2015
I don't think we should fix this issue. I think the fix is too costly and complex, and I don't think the issue is serious enough to warrant it.
Mohamed Hegazy (@mhegazy) Anders Hejlsberg (@ahejlsberg) Do you agree?
ahejlsberg commentedon Jul 3, 2015
I agree, I think we can close this one.