L = { tag: "a", payload: string } | { tag: "b", payload: number }
R = { tag: "b", payload: number } | { tag: "c", payload: boolean }
T = L | R
For all purposes and intents, the "b" type in L and R should be treated the same, no? What do you gain by not doing that??
As a concrete example, consider a map with a method get(key: K) -> Option<V>. How do you tell the difference between a missing key and a key which contains `null` as a value?
With this type you would have to check/match an extra case!
The type you use there also takes more memory than Option<T> or Maybe<T>. So it has some other downsides.
It's like saying `string | "foo"` it is simply `string` due to subtyping.
If you have a function that will normally return a string, but can sometimes fail due to reasons, you may wish to yield an error message in the latter case. So you're going to be returning a string, or a string.
It's not what the content of the data is; it's how you're supposed to interpret it. You have two cases, success and failure, and control will flow differently depending on that, not based strictly on the type of data at hand. We just model those cases in a type.
You have missed the thread context, which is whether `Either a a` (also written `a + a`) has any merits over simply `a` (which is identical to `a | a`). If you're on the `Either` train already, we are arguing over imaginary beef.
> No disrespect, but that still sounds entirely useless to me.
It is disrespectful to say something "makes zero sense", regardless of anything you might say to the contrary. You've misrepresented my point: nobody wants to model something as `String | String`.
If you have, say, an `Int | Bool`, and you pass both sides through some kind of stringification function, you're naturally going to get `String | String` without ever having written that type down yourself. You wouldn't necessarily want to collapse that to `String`, however, because you may -- for instance -- want to give strings and ints different decorations around them before finally flattening them. You might write such a function as something like
(ib) => ib
.mapBoth(showInt, showBool)
.visit(prepend("int: "), prepend("bool: "));
You could write the same function without passing through `String | String`:
(ib) => ib.visit(
sequence(showInt, prepend("int: ")),
sequence(showBool, prepend("bool: ")));
And if I want `error` to be `string` so I can just provide an error message? Proper disjoint sum types let me keep the two sides disjoint, even if they happen to be the same type. Union types will collapse on any overlap, so if I happen to instantiate `error` at `string` then I can no longer tell my error case from my data case.
T = {tag: "L", payload: L} | {tag: "R", payload: R}