OT: (C#) Type Unions for C#

[Quirin Schroll]

On Monday, 12 August 2024 at 10:37:08 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
> On 12/08/2024 10:32 PM, Quirin Schroll wrote:
>> Tag-based type unions where order matters, duplication matters 
>> (different tags), they do not auto-inline, and the empty one 
>> is at definition site its own type.
>
> There is also tag based unions where order doesn't matter.
>
> I.e. hashed tag name/tag type.
>
> This is the one I propose, as it allows changing the sumtype 
> elements without having to perform a match.

What I intended was writing “Non-tag-based type unions where 
order matters” etc. where you extract by index.

For tag-based unions, you’re right, order should not matter, same 
as order of data members in a `union` type doesn’t matter.

The gist is: There are actually four kinds of type sums: 
Plus-like, list-like, and ad-hoc and user-defined tagged.

Examples:
- JSON values are reasonable as a plus type: `alias Json = double 
+ string + bool + Json[] + Json[string] + typeof(null)`.
- Value exceptions are list-like: `Result = Expected ~ 
Unexpected1 ~ Unexpected2`. An unexpected type might be identical 
with `Expected` but semantically different. Even two unexpected 
results might be same-type but semantically different. If that’s 
not intended, one can use `Expected ~ (Unexpected1 + 
Unexpected2)`.
- Most high-level user-defined sum types would be tag based.

I implemented something like that some time ago in a library. 
What the library does is provide a mixin template so that users 
can create their own tag-based sum types. What it didn’t offer, 
though, was ad-hoc tag based unions, probably because of limiting 
syntax. I didn’t like seeing `Sum!(int, "x", long, "y")` in error 
messages because those things get long quickly. For the mixin 
template, I use an “implementation struct” that provides the 
types and members.