OT: (C#) Type Unions for C# (page 2)

On Tuesday, 6 August 2024 at 19:44:12 UTC, Kapendev wrote:

On Friday, 2 August 2024 at 10:29:22 UTC, ryuukk_ wrote:

Some people over here like to take C# as inspiration for new DIPs

Well, tagged union is coming to C#, let's resurrect that old DIP and go submit a PR

Tagged unions in C# seem quite complex. 🤢
Maybe the OdinLang implementation might be a better inspiration: https://odin-lang.org/docs/overview/#unions

It seems Odin has type unions. I actually dislike their approach.

IMO, you have two sane approaches:

Plus-like type sums where order doesn’t matter, duplication doesn’t matter and they auto-inline. The empty plus-like sum is noreturn and adding noreturn to a plus-like doesn’t actually add it, so that S+(T+noreturn) is another way to spell T+S.
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.

From a plus-based type sum, you extract values asking for a value of some type. From a tag-based one, you request by tag.

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.

August 13

Re: OT: (C#) Type Unions for C#

Posted by Quirin Schroll
in reply to Richard (Rikki) Andrew Cattermole

Permalink

Quirin Schroll

Posted in reply to Richard (Rikki) Andrew Cattermole

Permalink

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.

Forums