Type assertion only works if one type is completely assignable to the other

[JsonFreeman]

interface Foo {
    a?: string;
    b: string;
}
<Foo>{ a: undefined } // Neither type is assignable to the other

This 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.

[JsonFreeman]

Another potential fix is to copy optional properties into an object literal during contextual typing if they are missing.

[ahejlsberg]

The right solution here is probably a new "is assignable to or from" relation as you suggest.

[JsonFreeman]

Per issue #2441, we can use this for equality comparisons too.

[JsonFreeman]

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.

@mhegazy @ahejlsberg Do you agree?

[ahejlsberg]

I agree, I think we can close this one.