[Discussion] Nominal Type Unions

[mattwar]

Proposal document:
https://github.com/dotnet/csharplang/blob/main/proposals/nominal-type-unions.md

Original Proposal:
https://github.com/dotnet/csharplang/blob/main/meetings/working-groups/discriminated-unions/original-nominal-type-unions.md

Issue for proposal:
#9411

[colejohnson66]

#9246 is for expressions

[orthoxerox]

It's #9411

[Richiban]

Has there been any discussion of a shorthand to better support the simple discriminated union use case?

By this I mean that this:

    public union Option<TValue>(Some<TValue>, None)
    {
        public record struct Some(TValue Value);
        public record struct None();
    }

still feels bit too verbose to me. It doesn't feel great that the "cases" of the union have to be repeated when what I want to write is something like

    public union Option<TValue>
    {
        case Some(TValue Value);
        case None();
    }

An example from a domain I'm working in would look something like this:

public union CallState(Initiated, Pending, InProgress, ApplyingFallback, Ended)
{
    public record struct Initiated();
    public record struct Pending();
    public record struct InProgress(ConferenceSid Sid, EventDateTime Started);
    public record struct ApplyingFallback(ConferenceSid? Sid);
    public record struct Ended(ConferenceEndReason EndReason, ConferenceSid? Sid, EventDateTime Ended);
}

That just feels like too much duplication and boilerplate.

[Richiban]

Yes, but why should case mean public record struct and not public record?

My thinking there was that it would because a union is a struct, but I'm fine with case meaning case class and then having case struct available as well, since that would give them symmetry with records.

[tuscen]

Another approach is to make it similar to how records behave: by default it could be a struct or a class. But you can specify it explicitly after the union keyword like so

This will make every case a record struct:

public union struct Option<TValue>
{
    case Some(TValue Value);
    case None();
}

And this will make every case a record class:

public union class Option<TValue>
{
    case Some(TValue Value);
    case None();
}

[myblindy]

An example from a domain I'm working in would look something like this

Both your example, and Option seem to be better mapped on top of extended enums. In Rust for example, I'd implement both of those with a simple enum with parameters for values. Its Option is even implemented as an enum in the standard library.

Are you sure you aren't advocating for extending enums to match most modern languages? This union proposal seems like a poor, verbose patch for proper enums in the language (though it does have some interesting applications in interop, for example).

[HaloFour]

Are you sure you aren't advocating for extending enums to match most modern languages?

That would fall under the umbrella of "discriminated unions", as tagged unions specifically, which is how they are implemented in Rust. This proposal is specifically exploring what it would look like to handle them as type unions in the language, where the cases are proper types. That approach solves for a lot of use cases where the cases would be types in their own right. It's the approach that both Scala and F# use for their Option types, although F# also has ValueOption which is a tagged union.

Syntax aside, I'd argue either strategy would solve 95% of the use cases equally well. Around the edges are cases solved better by one approach or the other. Without decent runtime support, I worry that the illusion of type unions will be brittle with jagged edges.

[mattwar]

We are saving design space for the existence of union structs, which is just more 'struct-y' than normal unions. Their cases would be record structs, and they would have non-boxing storage layouts.

[tuscen]

Do I understand it correctly that in case of type declaration being inside a union it will be a nested type inside the union?

I.e. this declaration

public union MyUnion
{
    public record struct Case1();
    public record struct Case2();
}

will be translated to

[TypeUnion]
public readonly struct MyUnion
{
    public record struct Case1();
    public record struct Case2();

    // ...
}

[mattwar]

Yes, that is what it means.

[tuscen]

Overall, I'm a bit disappointed that we might end up with type unions. On top of that, from what I understand, they seem to be a completely compile-time feature that the runtime doesn't know anything about, which leads to a bunch of foot guns during runtime with generic code.

I'd be much more satisfied with a carbon copy of F#'s DUs, which, in my opinion, cover 90% of use cases for discriminated unions: modeling domain objects.

[martin-steinhoefer]

Hi Matt,

how the following case would be handled?

interface IA { }
interface IB { }
abstract class C {  }
union U(IA, IB, C);

class D : C, 
    IA, IB {  } // this might be something, one is not aware of (private implementation) or may change over time

U u = new D(); 

The declaration of the type union contains neither duplicate case types, nor case types that are subtypes of another nor the all matching object type - so I would expect no error nor warnings.
Would all of the following match?

if (u is IA a) { ... }
if (u is IB b) { ... }
if (u is C c) { ... }

// which arm would be taken?
u switch
{
    IA a => ...
    IB b => ...
    C c => ...
}

[HaloFour]

I would expect all cases to match. As for switch arms, the first one would match as it would be tested first.

[mattwar]

It would behave the same as if u were typed as object. All would match. In a switch the first branch would be taken.

[ScottKane]

This is technically already possible in C# so adding unions should just be some lowering sugar to make working with it nice. I'm not a fan of any of the current proposals as they would lead to boxing when working with unions of value types, at least most of what I have seen so far. IMO rust just handles this well and we have most of the building blocks to make that happen.

Imagine the following:

union Test
{
    A(A),
    B(B),
    C(C)
}

Best we can do in C# today:

[StructLayout(LayoutKind.Explicit)]
public struct Test
{
    [FieldOffset(0)]
    private TagType Tag;
   
    // Variant A: Single int (4 bytes)
    [FieldOffset(4)]
    private A _a;
   
    // Variant B: Two ints (8 bytes)
    [FieldOffset(4)]
    private B _b;
   
    // Variant C: Three ints (12 bytes)
    [FieldOffset(4)]
    private C _c;
   
    public bool IsA => Tag == TagType.A;
    public bool IsB => Tag == TagType.B;
    public bool IsC => Tag == TagType.C;

    public A A => IsA ? _a : throw new InvalidOperationException();
    public B B => IsB ? _b : throw new InvalidOperationException();
    public C C => IsC ? _c : throw new InvalidOperationException();
    
    public override string ToString() => Tag switch
    {
        TagType.A => $"Test.A({_a.ToString()})",
        TagType.B => $"Test.B({_b.ToString()})",
        TagType.C => $"Test.C({_c.ToString()})",
        _ => throw new InvalidOperationException("Can never happen...")
    };

    private enum TagType
    {
        A = 0,
        B = 1,
        C = 2
    }
}

public record struct A(int Value1);

public record struct B(int Value1, int Value2);

public record struct C(int Value1, int Value2, int Value3);

Then:

Console.WriteLine(testA);
Console.WriteLine(testB);
Console.WriteLine(testC);

if (testA is { IsA: true })
{
    var a = testA.A;
    Console.WriteLine(a);
}

if (testB is { IsB: true })
{
    var b = testB.B;
    Console.WriteLine(b);
}

if (testC is { IsC: true })
{
    var c = testC.C;
    Console.WriteLine(c);
}

Console.WriteLine($"Test Size: {Unsafe.SizeOf<Test>()}");

Outputs:

Test.A(A { Value1 = 1 })
Test.B(B { Value1 = 2, Value2 = 3 })
Test.C(C { Value1 = 4, Value2 = 5, Value3 = 6 })
A { Value1 = 1 }
B { Value1 = 2, Value2 = 3 }
C { Value1 = 4, Value2 = 5, Value3 = 6 }
Test Size: 16

So if we add a bit of magic deconstructing to Test:

public void Deconstruct(out bool isA, out A a, out bool isB, out B b, out bool isC, out C c)
{
    isA = IsA; a = _a;
    isB = IsB; b = _b;
    isC = IsC; c = _c;
}

Then we can switch over it:

test switch
{
    (true, var a, _, _, _, _) => a...,
    (_, _, true, var b, _, _) => b...,
    (_, _, _, _, true, var c) => c...
}

So if we just have unions lower to a representation like this we could lower switch pattern matching from something like:

test switch
{
    Test.A(a) => a...,
    Test.B(b) => b...,
    Test.C(c) => c...,
}

This way we achieve the goal with minimal work. It should also be possible to have the lowered struct implement an interface:

union Test : ISummable
{
    A(A),
    B(B),
    C(C)
        
    public int Sum() =>
        this switch
        {
            Test.A(a) => a.Sum(),
            Test.B(b) => b.Sum(),
            Test.C(c) => c.Sum(),
            _ => throw new InvalidOperationException("Can never happen...")
        };
}

Becomes:

[StructLayout(LayoutKind.Explicit)]
public struct Test : ISummable
{
    [FieldOffset(0)]
    private TagType Tag;
   
    // Variant A: Single int (4 bytes)
    [FieldOffset(4)]
    private A _a;
   
    // Variant B: Two ints (8 bytes)
    [FieldOffset(4)]
    private B _b;
   
    // Variant C: Three ints (12 bytes)
    [FieldOffset(4)]
    private C _c;
   
    public bool IsA => Tag == TagType.A;
    public bool IsB => Tag == TagType.B;
    public bool IsC => Tag == TagType.C;

    public A A => IsA ? _a : throw new InvalidOperationException();
    public B B => IsB ? _b : throw new InvalidOperationException();
    public C C => IsC ? _c : throw new InvalidOperationException();
    
    public override string ToString() => Tag switch
    {
        TagType.A => $"Test.A({_a.ToString()})",
        TagType.B => $"Test.B({_b.ToString()})",
        TagType.C => $"Test.C({_c.ToString()})",
        _ => throw new InvalidOperationException("Can never happen...")
    };

    public int Sum() =>
        this switch
        {
            (true, var a, _, _, _, _) => a.Sum(),
            (_, _, true, var b, _, _) => b.Sum(),
            (_, _, _, _, true, var c) => c.Sum(),
            _ => throw new InvalidOperationException("Can never happen...")
        };

    public void Deconstruct(out bool isA, out A a, out bool isB, out B b, out bool isC, out C c)
    {
        isA = IsA; a = _a;
        isB = IsB; b = _b;
        isC = IsC; c = _c;
    }

    private enum TagType
    {
        A = 0,
        B = 1,
        C = 2
    }
}

public record struct A(int Value1) : ISummable
{
    public int Sum() => Value1;
}

public record struct B(int Value1, int Value2) : ISummable
{
    public int Sum() => Value1 + Value2;
}

public record struct C(int Value1, int Value2, int Value3) : ISummable
{
    public int Sum() => Value1 + Value2 + Value3;
}

public interface ISummable
{
    int Sum();
}

Obviously these public properties are just to validate that it works and wouldn't need to exist in the actual lowered code

[Kirisoup]

Instead of

[StructLayout(LayoutKind.Explicit)]
public struct TaggedUnion
{
    [FieldOffset(0)]
    private Tag tag;
   
    [FieldOffset(4)]
    private A a;
   
    [FieldOffset(4)]
    private B b;
   
    [FieldOffset(4)]
    private C c;

    private enum Tag
    {
        A = 0,
        B = 1,
        C = 2
    }
}

Maybe consider the following, which better aligns the fields.

// [StructLayout(LayoutKind.Sequential)]
public struct TaggedUnion
{
    private Tag tag; 
    private Union union;

    private enum Tag : byte {
        A = 0,
        B = 1, 
        C = 2
    }

    [StructLayout(LayoutKind.Explicit)]
    private struct Union
    {
        [FieldOffset(0)]
        private A a;

        [FieldOffset(0)]
        private B b;

        [FieldOffset(0)]
        private C c;    
    }
}

This does slightly increase the size as the max size of A, B, and C increases, but since the data is aligned, reading the value should be faster (and a ref for normal methods or Box<> for async methods should be passed if copy overhead is the bottleneck. )

[mattwar]

None of these layouts work if A,B or C are a combination of value types and reference types, since they cannot be overlapped. There are many layouts that do work specified in the original nominal type unions document: https://github.com/dotnet/csharplang/blob/main/meetings/working-groups/discriminated-unions/original-nominal-type-unions.md

[ufcpp]

More to the point, it becomes more complicated in the case of value types that include reference types, and it is impossible to support generic types.

[Kirisoup]

None of these layouts work if A,B or C are a combination of value types and reference types, since they cannot be overlapped. There are many layouts that do work specified in the original nominal type unions document: https://github.com/dotnet/csharplang/blob/main/meetings/working-groups/discriminated-unions/original-nominal-type-unions.md

You are right. My comment is just a quick improvement specific to ScottKane's code, assuming A B and C are solid unmanaged types, not necessarily related to the topic.

Though on the topic of tagged union as a general language feature, the compiler can maybe generate something like this depending on the type of cases the union is defined with:

[StructLayout(LayoutKind.Auto)]
public ref struct TaggedUnion
// `ref` if the union is declared with the ref keyword
{
    private Tag tag; 
    
    // if any cases are solid unmanaged types
    private Union unmanagedCases; 

    // if any cases are solid managed value types or generic T : struct, allows ref struct
    private Struct valueCases; 

    // if any cases are solid reference types or generic T : class
    private object referenceCases; 

    // if any cases are by ref types
    private ref byte byrefCases; 

    private enum Tag : byte { ... }

    [StructLayout(LayoutKind.Explicit)]
    private struct Union { ... }

    [StructLayout(LayoutKind.Auto)]
    private struct Struct { ... }
}

Example: https://gist.github.com/Kirisoup/e095e598eda0ab0b4b15be600a236130

[Kuurama]

This directly makes more sense considering we tend to lower allocation, even by adding spans and all in the language.
Since its a feature that might be so important later down the road, what makes a tagged union not even the current proposal? Why type erasure too? Maybe that is what they meant by a non boxing union type with the struct keyword, but we don't know yet either.

[Thaina]

This feature is recurringly came back to me

Is it also possible for ref union return with ref struct?

[mattwar]

Not as currently proposed, but there is an opening in the design to allow a future pure struct union (and ref struct union) with other storage layouts that would allow for ref structs like Span to be cases.

[Thaina]

While I am appreciate the type union with | syntax. Is it possible to preserve , for composite type declaration?

I mean I wish that I could define a virtual type, in similar manner to union, that was compose of some interfaces and maybe another class or struct

For example

public interface ICanFly { void Flying(); }
public interface IHaveVoice { void DoVoice(); }

public abstract class Animal {}
public abstract class Mammal : Animal {}
public abstract class Insect : Animal {}

public abstract class Machine {}

public class Dog : Mammal,IHaveVoice {}
public class Cat : Mammal,IHaveVoice {}
public class Bat : Mammal,ICanFly,IHaveVoice {}
public class Bird : Animal,ICanFly,IHaveVoice {}
public class Fish : Animal {}
public class Ant : Insect {}
public class Fly : Insect,ICanFly {}
public class Cicada : Insect,ICanFly,IHaveVoice {}
public class BuzzingSpider : Insect,IHaveVoice {}

public class Car : Machine,IHaveVoice {}
public class Plane : Machine,ICanFly {}
public class Drone : Machine,ICanFly,IHaveVoice {}

Type composition can be so complex. So sometimes I wish I could have type declaration in similar manner to generic constraint. So that we could pass the type composite parameter even without generic, or make field/property/return type declaration with strict object type

Such example above I could

public typeof FlyingAnimal (Animal,ICanFly); // don't know what keyword should be used but the syntax could be similar to union

public typeof AnyFlyingNoisyThing (ICanFly,IHaveVoice); // match Bird, Bat, Cicada, Drone

public typeof AnimalThatCanDoSomething (Animal,ICanFly | IHaveVoice); // maybe can also mix union and composition?

public union ICanDoSomething (ICanFly | IHaveVoice);
public typeof MachineThatCanDoSomething (Machine,ICanDoSomething);

Alternatively we could use &. But then that syntax would be too differ from generic constraint?

On the other hand, could generic constraint also allow type union and & syntax too?

[mattwar]

It seems like you are asking about a type that is an 'and' type, where as a union is more of a 'or' type.

[Thaina]

@mattwar Correct, I know this is out of scope of this proposal, but still I would like to have consider possibility that in the future we might not only define or type but also and type in the same line. Should we preserve syntax for that

Actually because , is always being used to define and in C# at inheritance and generic constraint. At a glance it would be confusing even with union keyword, so should union still used | instead of , at declaring too is one thing I want to propose

Another thing is, what if we just define a keyword that, instead of just union it can define both union and composite type in the same line. That's why I just came up with reusing typeof

public typeof AnimalThatCanDoSomething (Animal,ICanFly | IHaveVoice);
// or if it would be confused with tuple
public typeof AnimalThatCanDoSomething (Animal & (ICanFly | IHaveVoice));

Or we may just use union anyway ?

public union AnimalThatCanDoSomething (Animal & (ICanFly | IHaveVoice));

And I mean, in this version we might only allow union first. But in some future would and relation also be allowed to defined too?

[mattwar]

I see, however, your suggestion is a very different kind of type than in the nominal type unions proposal. They are more of a constraint than an actual type. Have you proposed it separately in its own discussion topic?

[Thaina]

I see, however, your suggestion is a very different kind of type than in the nominal type unions proposal. They are more of a constraint than an actual type. Have you proposed it separately in its own discussion topic?

There was already #399

[bzd3y]

Throwing these syntax ideas out there to bump them if they have already been proposed or introduce them if not. The current syntax I have seen, something like public union Pet(Dog, Cat, Bird);, seems off to me since it isn't really like any other C# construct (although that is happening with a lot of new syntax) and looks too much like a function that has types passed in as arguments, but without being generic (which I would guess it probably is under the hood).

public union Pet : Dog, Cat, Bird; // "reuse" inheritance syntax, though it is more like "reverse" multiple inheritance, treating the : as the declarative "is" (or "can be") statement that it is conceptually anyway`

public union Pet<Dog, Cat, Bird>; // "reuse" generic syntax, similar to the idea of Nullable<T>, but "pass" the types to be unioned in

public union Pet // something like enum syntax
{
    Dog,
    Cat,
    Bird
}

The last one is probably the superior option since it seems the most conducive to declaring types within the union (that possibly can only be assigned to the union type if "private"?). So that would look something like this:

public union Pet // something like enum syntax
{
    Dog, // these are declared somewhere else
    Cat,
    Bird,
    public class Fish // this can presumably be used without using the union, but is just organized here as part of the union
    {

    },
    private class Rock // this can presumably only be used with the union?
    {

    }
}

I'm not sure about the private/public modifiers on the nested types. private might mean that the type can only be used with the union (so like an enum value might be to an int). So Pet pet = new Rock(); is valid, but Rock pet = Rock() is not? public might mean that the type can be used like any other type and is just organized under the union type, so Fish fish = new Fish(); would be valid.

private/public just seem like they might be the wrong words here, but I'm not sure this would be worth introducing another.

Another reason the last one is probably superior is that it could be formatted into a single line, much like the others:

public union Pet { Dog, Cat, Bird };

[bzd3y]

Neither is the case (no pun intended) with unions. None of these are "passing in" a type.

I know, but it LOOKS like they are. That was kind of my problem with it.

That said, I think the best argument that could be made to not use this syntax is that it mildly implies that multiple types are present, ordered, and may be supplied at a time.

Yes, and that is probably my main concern and why I "pushed" or. I think "suddenly" applying | to types here when or was arrived at for type patterns would be a mistake, albeit maybe an inconsequential one.

[CyrusNajmabadi]

I know, but it LOOKS like they are.

I guess our point is: the language already has been fine with other places that look like this not meaning that. So this is not new, and it hasn'tbeen a problem so far. So worrying about that for this isn't that compelling to us.

[bzd3y]

Fair enough, but that also seems to contradict above where you said this:

That said, I think the best argument that could be made to not use this syntax is that it mildly implies that multiple types are present, ordered, and may be supplied at a time.

And that is really all I am saying, you just said it better. Then again, maybe that still isn't a compelling reason to you.

[CyrusNajmabadi]

Then again, maybe that still isn't a compelling reason to you.

yes. it's something i noticed, but found incredibly mild. After looking at this for 5 minutes, it started feeling just fine and i stopped caring entirely :)

[bzd3y]

Fair enough. That just seems like another case where there was no point in really any public discussion about it, and it just comes down to the internal team that is going to implement it all should decide. I am completely fine with that. I just get caught up on details other people don't care about.

[jnm2]

Throwing more spaghetti at the wall:

public union Pet = Dog | Cat | Bird
    : IExtraInterface
{
    // other members
}

[mattwar]

We have not formally proposed Option or Result types yet, but we use them a lot in examples and as use-cases for unions. They both are specific instances of unions that traditionally have additional language behavior associated with them. It's that additional behavior that is unfortunately a bigger design issue than unions are in general.

[Serdan]

@bzd3y everything can be done without unions. Every language with unions implements Option/Result as unions. It's a textbook example of a union type.

type Option<'a> = Some of 'a | None

Compare with a C# implementation.

[bzd3y]

everything can be done without unions.

No, not really... unions can't be done without unions. The Result<T, TError> example given can't be done without unions. An option type might be a union in type theory and other languages, but this is C#, not those other things. That's all I meant.

Again, I was also confused and had it in my head that for some reason we were talking about generic unions with types that were not part of the union, and I was having trouble with that concept.

[Thaina]

everything can be done without unions.

No, not really... unions can't be done without unions. The Result<T, TError> example given can't be done without unions. An option type might be a union in type theory and other languages, but this is C#, not those other things. That's all I meant.

Again, I was also confused and had it in my head that for some reason we were talking about generic unions with types that were not part of the union, and I was having trouble with that concept.

That is actually a union. You just making subset of union, a specialized fake union

Sure, we can make do just about anything to avoid making union by faking union with existing features. It just not practical to avoid union for eternity compare to just adopt union already and make everyone life easier

[bzd3y]

@Thaina ... Why are you guys dwelling on this? I understand it is a union in type theory. It would not need to be in C#. There's nothing really controversial about that. I understand the point you guys are making now.

You just making subset of union, a specialized fake union

No... there would really be nothing "union" about it, not any more than Nullable<T> is a "fake union".

But this really doesn't matter for the discussion and I'm more on the same page as everybody else now.