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
When dealing with object literals, we know exactly what properties are present.
So the idea is: whenever fresh object literal types occur together in a union, we can factor them into a more well-understood type.
This new process is called object literal type normalization, and is performed during widening.
This means that if widening does not need to occur, normalization doesn't occur.
For example, if an explicit type is given, we don't need to widen, so we verify against the most exact version we start with.
// 'objs' has an element type of// { a: number, b: number } |// { a: string, b?: undefined } |// { a?: undefined, b?: undefined }letobjs=[{a: 1,b: 2},{a: "abc"},{}];letobj=obj[randomInt()];obj.a;// string | number | undefinedobj.b;// number | undefined
We need to look into this-types, since we don't use normalized properties in that context.
What about when you're in non-strictNullChecks mode?
If you have one object with color and another with colour, now both are available, whereas before you'd get {} which would eventually raise your own suspicions when you couldn't use the types.
Yes, it is a step backwards in this regard.
Why don't we just always include | undefined on properties that occur in a union of object types?
e.g.
declareleta: {x: ''};declareletb: {};letobjs=[a,b];objs[0].x// should this be 'string | undefined'?
No, you don't have a license to do this because the object types may have other properties that aren't listed; this only works with exact types.
This is techncally a breaking change because previously we would eventually infer {}.
That means anything was subsequently assignable.
Does that come up often? Is that even desirable?
Real world code didn't break at all.
What about in type argument inference?
Yes, we do the same thing now as well.
So given all of this work, do we want to continue even doing best-common-supertype inference? Why not just return a union?
Most cases where we looked into this seemed undesirable.
Improved inference for object literals
#19513
this
-types, since we don't use normalized properties in that context.strictNullChecks
mode?color
and another withcolour
, now both are available, whereas before you'd get{}
which would eventually raise your own suspicions when you couldn't use the types.| undefined
on properties that occur in a union of object types?e.g.
No, you don't have a license to do this because the object types may have other properties that aren't listed; this only works with exact types.
{}
.Better error spans in array literals
#19236
Tuple freshness & stricter tuple behavior
#19463
length
property?ReadonlyArray
?strictTupleTypes
?The text was updated successfully, but these errors were encountered: