The Elephant in the Room + Wish List — Syntax of Discriminated Unions

[Unknown6656]

DUs are expected to be the flagship feature of the next C# version.
However, I am under the impression to have heard surprisingly little about DUs considering that they will come out next year (compared to records, which were in discussion since 2014, IIRC).

I expect DUs to be implemented as abstract classes/records with private constructors. Each DU case would be a nested class of the DU and implement the parent DU. The nesting gives them exclusive access to the private base constructor.

This would be comparable to my own version of DUs:
I use T4-Templates to generate these kind of classes:

public abstract class Union<T1, T2>
{
    public virtual bool IsCase1 => false;
    public virtual bool IsCase2 => false;

    private Union() { }

    public abstract void Match(Action<T1> if_case_1, Action<T2> if_case_2);
    public abstract T Match<T>(Func<T1, T> if_case_1, Func<T2, T> if_case_2);

    public static implicit operator Union<T1, T2>(T1 value) => new Case1<T1, T2>(value);
    public static implicit operator Union<T1, T2>(T2 value) => new Case2<T1, T2>(value);

    public sealed class Case1<T1, T2> : Union<T1, T2>
    {
        public override bool IsCase1 => true;
        public T1 Value { get; }

        public Case1(T1 value) : base() => Value = value;

        public override void Match(Action<T1> if_case_1, Action<T2> if_case_2) => if_case_1(Value);
        public override T Match<T>(Func<T1, T> if_case_1, Func<T2, T> if_case_2) => if_case_1(Value);

        public static implicit operator T1(Case1<T1, T2> union_case) => union_case.Value;
    }

    public sealed class Case2<T1, T2> : Union<T1, T2>
    {
        public override bool IsCase2 => true;
        public T2 Value { get; }

        public Case2(T2 value) : base() => Value = value;

        public override void Match(Action<T1> if_case_1, Action<T2> if_case_2) => if_case_2(Value);
        public override T Match<T>(Func<T1, T> if_case_1, Func<T2, T> if_case_2) => if_case_2(Value);

        public static implicit operator T1(Case1<T1, T2> union_case) => union_case.Value;
    }
}

These are used as follows:

Union<int, bool> my_union = 42;

my_union.Match(i => Console.WriteLine("It's an int! " + i), b => Console.WriteLine(It's a bool!" + b));

---

My solution is far from ideal. I absolutely adore the F# syntax, but this would be impossible to adapt identically into C#.
So, my question is: What could the syntax of future DUs look like?

// like this?
public union MyUnion
{
    public case int;
    public case bool;
    public void Print() => Console.WriteLine("I am a " + this);
}

MyUnion my_union1 = false;
union { int; bool; } my_union2 = 42; // anonymous unions?

I am under the (probable wrong) impression, that the DU's future syntax has not yet really been addressed by the LDT, which is the reason why I will use the clickbait-headline of "the elephant in the room".

I also want this discussion to be like a Christmas whish list:
Please to comment which syntaxes you want to see for DUs!

[HaloFour]

This is in the working set for C# 10.0 so I expect that there will be quite a few discussions about the behavior and syntax of DUs coming out of language design meetings early in the next year. I'd suggest that a great deal about the design of DUs still must be hammered out, including their implementation details.

For instance you suggest that DUs might be based on abstract classes. That might be the case, but I'd suggest that requiring another allocation for a data container around your data is pretty expensive, especially for common DUs like Maybe<T> or Either<L, R>. I'd suggest that an option to generate a tagged union would be better in those cases. For single case unions the runtime could elide the struct entirely.

However, if it has to be about syntax, I would probably go with something like the following:

public struct enum Maybe<T> {
    Some(T Value),
    None
}

[HaloFour]

@DavidArno

That patent expires in 2022, I believe. If it's a real issue, just delay DUs by a year.

Adjusted expiration is 2024/02/01.

So I guess the question is whether or not it's waiting an additional three years? 😄

Languages like Swift and Scala have quite capable DUs and DU syntax without seemingly stepping on this patent, so I personally don't think it's necessary to do so.

[DavidArno]

@HaloFour, OK that shoots that idea down in flames. I'm not waiting that long! 😱

At least there is a delicious irony in knowing that Neil is one of the people that has to figure out how to work around that patent in order to deliver us DUs...

[HaloFour]

@DavidArno

At least there is a delicious irony in knowing that Neil is one of the people that has to figure out how to work around that patent in order to deliver us DUs...

Except that he left the team in September. 😢

[Unknown6656]

@orthoxerox @HaloFour These syntax proposals are not bad .... however I'm not sure whether I like the , as separator.
, would fit in nicely with enum members, but there is this inconsistency of mixing , and ;.
Furthermore, struct enum would imply that these are structs, which is incorrect if they are implemented with records .... should we propose class enum instead?

---

@DavidArno

So I guess the question is whether or not it's waiting an additional three years?

Whaaaaaaaat ....... f██k no! I'm not waiting that long!

---

@HaloFour

Except that he left the team in September.

Wait, really? Why? :/

[DavidArno]

@HaloFour,

I too missed that news. Gutted that he's gone and that I didn't even notice. Does explain why he's been so quiet recently, 😢