GeezerVison

Jason Freeman (@JsonFreeman) Thought this might interest you!

Whoa, interesting! That's true about fresh object literals failing the subtype test for subtype reduction. I have two general questions:

1. Is there any concrete benefit to having subtype reduction (given the new way of computing signatures of union types), or is it just for simplicity - to avoid having an extra type relation?
2. What is the difference between this incarnation of subtype reduction and the way it used to be? Presumably this fact about fresh object literals not getting thrown away would have applied before as well.

👍

Is there any concrete benefit to having subtype reduction (given the new way of computing signatures of union types), or is it just for simplicity - to avoid having an extra type relation?

It's mostly a backwards compatibility thing. We've seen several examples of real world code that was broken by the new behavior. The breaks all had to do with call signatures disappearing because a union type didn't get reduced to a single supertype. Of course it doesn't hurt that this new (or perhaps I should say old) way of doing things is also simpler in that there isn't a new kind of type relationship we have to document and reason about.

What is the difference between this incarnation of subtype reduction and the way it used to be? Presumably this fact about fresh object literals not getting thrown away would have applied before as well.

Consider this example:

var a = [{ x: 1 }, { x: 2, y: 2 }];  // ({ x: number } | { x: number, y: number })[]

Because the elements have fresh object literal types they aren't subtypes of each other, so the element type of the array literal is a union type. As we widen the type of the array literal we make sure _not_ to perform subtype reduction again as that would collapse the union when the object literal types lose their freshness. So, the full type survives as the type of a and the array literal is assignable to a. That previously wasn't the case (at one point in the evolution of #3823 we were in a state where the above was an error), and that's really the big difference.

Anders Hejlsberg (@ahejlsberg) Got it. Thanks for the explanation! So the difference is that noSubtypeReduction is true for the call to getUnionType in getWidenedType? That would seem to be the trap where subtype reduction is dangerous.

The scheme of aggregating the signatures of a union type is remaining as is, correct? I think it's still good for union types that didn't collapse under subtype reduction.