Repository navigation
Weird behaviour with union types and 'strict' object literals #5237
Description
I'm not sure if this a bug or by design, but it's confusing me:
interface Constraint {
message?: string;
}
var badConstraint: Constraint = {
messge: "rte" // errors as expected
};
var goodConstraint: Constraint | boolean = {
messge: "rte" // I expect this to error!
};Can anybody explain what is going on here?
Activity
jonnystoten commentedon Oct 13, 2015
In fact, changing
booleantoBooleanfixes the problem. Is this something to do with primitives in union types?RyanCavanaugh commentedon Oct 14, 2015
Obviously undesirable behavior, but it's behaving to the spec as currently written:
The property
messgeis "expected" (in the spec sense of the word, not plain English!) inConstraint | booleanbecause that type "is a union [...] type", andmessgeis "expected" inbooleanbecauseboolean"is not an object, union, or intersection type".So we see that the property is "expected" in the target type, and normally this would be OK because we would fail a later assignability check. But instead we successfully assign
{ messge: string }to{ message?: string }because it has all required properties.The proposed fix implemented in #3842 would flag this as an error. We should review that fix as it has broader good implications besides this one.
RyanCavanaugh commentedon Oct 20, 2015
Do we have an issue tracking the spec update?
ahejlsberg commentedon Oct 20, 2015
Ryan Cavanaugh (@RyanCavanaugh) No, we don't.