Negated Types: Define Extract and Exclude in terms of intersections and negations

[Wesley Wigham (weswigham)]

Swaps Extract to T & U and Exclude to T & not U, instead of their current conditional forms.

This isn't a strict improvement - in some ways, it's a step backward. On the extreme end, consider that Extract<T, any> previously yields T, but now yields any - the substitution behavior in conditionals hides the type erasure any (top level or nested) performs.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Note

This error may be related to your runner configuration. You can now configure runners for Copilot code review separately from Copilot cloud agent by creating a copilot-code-review.yml file with your setup steps. Read the docs for details.

[Mateusz Burzyński (Andarist)]

I've played a little bit with something recently and this difference came to my attention:

type S = { kind: "a" | "b"; value: number };
type A = { kind: "a"; value: number };
type B = { kind: "b"; value: number };

type Nested = Exclude<Exclude<S, B>, A>; // { kind: "a" | "b"; value: number; }
type Merged = Exclude<S, A | B>; // never

This PR "fixes" that - both of those reduce down to never (I've checked). I think this makes more sense for an average user, it makes for an interesting test case so it might be worth adding to this PR.