Normalize union/intersection type combinations

[ahejlsberg]

With this PR we normalize combinations of intersection and union types based on the distributive property of the & type operator over the | type operator. Specifically, because X & (A | B) is equivalent to X & A | X & B, we can transform intersection types with union type constituents into equivalent union types with intersection type constituents and thus ensure that union types are always at the top level in type representations and equivalent ways of writing the same type are treated identically.

interface A { a: string }
interface B { b: string }
interface C { c: string }
interface D { d: string }

// Identical ways of writing the same type
type X1 = (A | B) & (C | D);
type X2 = A & (C | D) | B & (C | D);
type X3 = A & C | A & D | B & C | B & D;

In the example above, X1, X2, and X3 are all identical types that reference the normalized form A & C | A & D | B & C | B & D.

Fixes #9919.

[sandersn]

One question about isRelatedTo and a possible improvement for reporting errors with intersections of boolean.

[sandersn]

Is there some way to present this error as number & boolean still? I feel like the distributed form is unexpected here.

[ahejlsberg]

The actual representation needs to be (number & true) | (number & false), but we could play tricks in the type-to-string logic to turn it into number & boolean. Not sure it's worth it though as those types are all rather meaningless anyway.

[sandersn]

Yeah, type-to-string is what I was thinking of. But you're right, & boolean probably only shows up in our tests.

[sandersn]

why not check the source first here too? I think that's the normal pattern for isRelatedTo

[ahejlsberg]

The comment above the initial if statement explains why. For intersection types, the target side is an "each" relationship and the source side is a "some" relationship. We need to deconstruct "each" relationships first to get the correct results.

[sandersn]

OK, so I think I misunderstood the parts of the code that are independent post-distribution. It would work to put intersections before unions now, where it wouldn't before, right?

[sandersn]

OK, so I think I misunderstood the parts of the code that are independent post-distribution. It would work to put intersections before unions now, where it wouldn't before, right?

[sandersn]

Yeah, type-to-string is what I was thinking of. But you're right, & boolean probably only shows up in our tests.