Official proposal for Type Unions in C#

I've been writing C, C++, C# and some js/sql/ts/python for money. Lua for lulz.

And *nothing* gets even fucking close in terms of productivity to C#.

Great language, mature and robust ecosystem with sane compilation times and

great tooling: package manager, test runner, strong debugger, one CLI with almost all tools needed.

I wish C++ was half as enjoyable as C# is.

C# is great, likely the best mainstream programming language nowadays, but its in the hands of microsoft and microsoft didn't really care much about building a community or getting it to work natively in other OSes/toolchains.

Its a shame, they even had a second change when Oracle bought sun and no one knew what was going to happen with Java, but fumbled that as well.

Instead of C#, why not F#? You get proper ADTs among many other great features, but you still get all the utility of the .NET ecosystem.

It's incredibly hard to go back to a language without even basic ADTs after seeing the light.

How did we ever prioritize implementation inheritance over ADTs?

I don't know, but it was a mistake.

You must really hate REPLs. You cling to your ADTs, I cling to my REPLs.

For me its C# and Python, though I like Rust, D and lately been getting into Nim. I want to like Lisp, but its just not something I see someone paying me to work in.

It's possible to add DUs in C# today with some third party packages.

- https://github.com/domn1995/dunet

- https://github.com/mcintyre321/OneOf

Quite good and ergonomic with the source generators removing a lot of the boilerplate.

I have a practical example here using OneOf with .NET Channels: https://chrlschn.dev/blog/2024/07/csharp-discriminated-union...

For me it's Elixir / Golang and Rust. Between these 3 I can serve all needs.

I was disappointed with Rust not being able to do ad-hoc unions, as well as the flippant you don't need that mentality of the community.

I’m in the same boat, and while I love the concepts behind Rust I’m not a fan of the syntax.

What I’d love to see is a hybrid between C# and Rust that has the capabilities of both languages in “layers”.

So business logic would be written in a simple GC variant of the language that feels like C# but the underlying standard library and low-level packages could use Rust-like semantics.

This is already the direction that C# is moving in: it’s getting more and more features related to “ref” and other low-level primitives.

Sadly Rust and C# have fundamental incompatibilities such as different string encodings, so they can’t be directly merged.

I also really like rust's support for deriving traits. Being able to generate hashes, equality, debug strings, etc., is really convenient for hacking around.

F# is so hard to walk back from. I wish Microsoft would support it better and actually push it, because it's such a perfect sweet spot. Most of the functional advantages without being shackled to pure functions and the like is so easy to develop in.

Instead they've been, very slowly, turning C# into F#, which is even weirder to watch.

Good news is that you can achieve this with relatively little boilerplate in Java with sealed interfaces and records now. Relative to Java that is

As of 2020 (when I stopped using F# and .Net in general), the CLR only had inheritance and F#'s enums were actually implemented using inheritance. Eg Some and None were derived classes of Option class. You would see it if you inspected an F# assembly in a decompiler. I don't know if it's still the same today. This C# proposal has anonymous enums using `A or B` syntax which would be hard to make work as sugar over inheritance, so I guess the CLR would support enums first-class for this to work (if it doesn't already).

Java is generally fine enough, but it's a little annoying when I have to do whacky workarounds with wrapper classes to get something that would be done in three lines

This is a weird take, given that Java has had ADTs for years

Records https://en.wikipedia.org/wiki/Java_version_history#Java_16

Sealed classes https://en.wikipedia.org/wiki/Java_version_history#Java_17

And pattern matching for almost a year https://en.wikipedia.org/wiki/Java_version_history#Java_21

Otherwise big agree on how delightful to work with F# is.

Hmm. You find it hard to go back to languages without ADTs yet you use Java for your day job. Okay.

FYI, Java has tagged union types (since version 16).

Pattern matching too.

I have the same objection but coming from the other side. The mainstream languages used to have pervasive mutation and side-effects. Now they have pervasive mutation and side-effects with lambdas.

But my question is: what is missing from the OO side? What would it take for C# and/or others to "do OO well"?

What does "better OO" mean here?

Which concepts or feature you have on mind?

TypeScript has "union types". This proposal refers to them as "ad hoc unions". I don't think "type union" is a term of the art - at least I haven't heard it before. It seems to be something the C# people are making up to describe sum types.

Going from C# to Typescript with type unions it always felt weird. Maybe that’s a good reason to have held off on this for this long? Know your audience and all that?

It does get used to but still reading the too many A|B|undefined gets tiring after a while. It also adds to laziness as you could take one thing and be fuzzy about returning a combo of three or more things. And as you go up the stack this gets more and more confusing.

C# forces you to deal with this in a constrained way which I like.

But perhaps there are folks who are excited by this that have a convincing argument? Please educate me.

You won't be able to leverage C#'s pattern-matching effectively with a library.

Really though, you don't need a library to do sum-types in C#:

It's best to just use records for now:

    public abstract record Maybe<A>
    {
        private Maybe() { }

        public sealed record Just(A Value) : Maybe<A>;
        public sealed record Nothing : Maybe<A>;
    }

You can then construct like so:

    var mx = new Maybe<int>.Just(123);
    var my = new Maybe<int>.Nothing();

   var r = mx switch
   {
      Maybe<int>.Just (var x) => x,
      Maybe<int>.Nothing      => 0
   };

And, if you want a load of pre-built ones, then my library language-ext will help [1]

[1] https://github.com/louthy/language-ext/

The linked says "Proposed, Prototype: Not Started, Implementation: Not Started, Specification: Not Started"

.NET releases are every November, and I would be very surprised to see this in November 2024. More likely November 2025 at soonest. But check back to that page later.

It's a different kind of ugly, but you can use the Visitor pattern to get the same exhaustiveness checking at compile time without a library.

3 years away at least.

There is no timeframe right now. At the moment this is a loose proposal for how to approach union like features in C#. There are a lot more details to dig into here before we'd be ready to move to scheduling and implementation. Also need to decide if we take on all of the union variants proposed or just some and what priority order to approach them.

It's not a bad idea to evaluate OneOf. This proposal relies on records, so every use instance requires heap allocations and dereferencing which has memory and time implications respectively.

I implemented my own option types entirely differently via ref structs where the "non-option" becomes either a default of a value type or a null reference (size of a pointer). Then (in theory) the overhead is reduced to a single dereference with everything else being stack-allocated.

I then built the same thing as a non ref (regular) struct version for storing in a field. So I have Options.Quick and Options.Long namespaces with practically the same struct design just the former is a ref struct.

This has served me very well, is very fast. It just doesn't have the exhaustive checking and risks derefing a null reference, but in practice is not a big issue.

   if(option.IsT1){ doSomething(option.ValueT1)};
   if(option.IsT1){doSomething(option.ValueT2)}; // this would throw an exception, i.e. a bug, but its very readable to catch the bug

Maybe I'm off, but to me the gist of the expression problem can be explained by contrasting how code extensibility is achieved in OOP/FP.

OOP Approach with interface/inheritance:

Easy: Adding new types (variants) of a base class/interface. Hard: Adding new functionality to the base class/interface, as it requires implementing it in all existing types.

FP Approach with Discriminated Unions:

Easy: Adding new functions. Create a function and match on the DU; the compiler ensures all cases are handled. Hard: Adding new types to the DU, as it requires updating all existing exhaustive pattern matches throughout the codebase.

Here's some Kotlin code. Kotlin is great because it can do both really well.

  // Object-Oriented Approach
  interface Shape {
      fun area(): Double
      fun perimeter(): Double
  }

  class Circle(val radius: Double) : Shape {
      override fun area() = Math.PI \* radius \* radius
      override fun perimeter() = 2 \* Math.PI \* radius
  }

  class Rectangle(val width: Double, val height: Double) : Shape {
      override fun area() = width \* height
      override fun perimeter() = 2 \* (width + height)
  }

  // Easy to add new shape
  class Triangle(val a: Double, val b: Double, val c: Double) : Shape {
      override fun area(): Double {
          val s = (a + b + c) / 2
          return Math.sqrt(s \* (s - a) \* (s - b) \* (s - c))
      }
      override fun perimeter() = a + b + c
  }

  // Hard to add new function (need to modify all existing shapes)
  // interface Shape {
  //     fun area(): Double
  //     fun perimeter(): Double
  //     fun draw(): String  // New function
  // }

  // Functional Approach
  sealed class ShapeFP {
      data class CircleFP(val radius: Double) : ShapeFP()
      data class RectangleFP(val width: Double, val height: Double) : ShapeFP()
  }

  fun area(shape: ShapeFP): Double = when (shape) {
      is ShapeFP.CircleFP -> Math.PI \* shape.radius \* shape.radius
      is ShapeFP.RectangleFP -> shape.width \* shape.height
  }

  fun perimeter(shape: ShapeFP): Double = when (shape) {
      is ShapeFP.CircleFP -> 2 \* Math.PI \* shape.radius
      is ShapeFP.RectangleFP -> 2 \* (shape.width + shape.height)
  }

  // Easy to add new function
  fun draw(shape: ShapeFP): String = when (shape) {
      is ShapeFP.CircleFP -> "O"
      is ShapeFP.RectangleFP -> "[]"
  }

  // Hard to add new shape (need to update all existing functions)
  // sealed class ShapeFP {
  //     data class CircleFP(val radius: Double) : ShapeFP()
  //     data class RectangleFP(val width: Double, val height: Double) : ShapeFP()
  //     data class TriangleFP(val a: Double, val b: Double, val c: Double) : ShapeFP()
  // }

I wrote this to help me understand the differences.

https://deliberate-software.com/christmas-f-number-polymorph...

A simple example is the Result<T> which could have either Ok(T value) or Error(string message). In order to get the value you need to switch over both cases, forcing you to handle the error case locally.

I think the most down to earth example is the AST or data protocol examples. Take Jason for example. Instead of having a JsonValue class to hold the data you would have a Union type that is either string, bool, number, array of your union type or map type which uses a string as key and the same union type as value. It would also allow to implement result types like rust has them. So you could define an API that returns a value or an error. I didn’t see in the proposal if they talked about generics though. In functional programming world this is mainly known as algebraic data types. I can say that if you get used to model types like this you really start to miss it in languages that don’t support it.

[1] https://en.m.wikipedia.org/wiki/Algebraic_data_type

We have been using empty interfaces to simulate F# discriminated unions for the last 5+ years. It works like a charm. The problem "not all cases are handled in the switch" occurs very rarely (once per 50k lines of code) and, usually, we fix it after the first run of a smoke test. So, it's not a problem at all.

I think,.net team haven't added discriminited unions yet because it can be effectively simulated with interfaces.

This[0] lib implements F#-style discriminated unions. The way I've used it is to make my outer layers return "Result" types that wrap the DTO, error, etc. under one umbrella. It allows for pattern matching your results which makes error handling easier and also allows your models to evolve over time without changing your function signatures at the edge.

[0] https://github.com/mcintyre321/OneOf

Like an enum, a union have a closed set of elements so it can be statically checked all cases are handled.

With an interface, someone could add a new implementation, causing codee to fail at runtime.

That type of hierarchy is “open” in the sense that when you handle them you can’t know whether you handled all of them. Anyone can make a new implementation of your interface, potentially in code that isn’t yours.

Also, the options may not share any surface area at all, so the “interface” for all the types may be empty which is a bit unnatural in OO.

But under the hood, it’s just this: a type hierarchy. But the hierarchy is closed for extension, and (this is the key part you’d not get if doing this “manually” as you describe) when code uses the cases, failing to account for a case will cause an error at compile time.

I found this video quite useful in showing the new proposal in action.

https://youtu.be/aksjZkCbIWA

AFAICT from a quick skim of the proposal is actually includes both sum types (called union types) and union types (called ad hoc unions) under the same proposal. This is, to me, very confusing. They work in very different ways.

I find it strange and slightly confusing that tey call it "union types". The correct term would be "sum types" or "discriminated union types"...

You mean like this?

A proposal for type unions (aka discriminated unions) in C#.

Discriminated unions are a type of union type, hence the name, and in terms of how they're used in everyday development they fill a very similar role. If they have no intention of supporting pure TypeScript-style unions (which I'm sure they don't) then I don't know what the harm is of shortening "discriminated union" to "union" in the context of C#.

The proposal does both sum types and union types.

"Tagged" sounds like an implementation detail to me (that it has a "tag" internally to tell between types). I suspect they added "type" to "union" to make it clear what is about (about types). The syntax itself has just "union", judging by the document.

UPD. They have this in the FAQ:

  Q: Why are there no tagged unions?
  A: Union structs are both tagged unions and type unions. Under the hood, a union struct is a tagged union, even exposing an enum property that is the tag to enable faster compiler generated code, but in the language it is presented as a type union to allow you to interact with it in familiar ways, like type tests, casts and pattern matching.

Because the proposal is about several kinds of unions:

- closed hierarchies of reference types that the compiler will verify at build time

- value types that use compiler tricks to behave like closed hierarchies (tagged unions)

- custom types that can have any implementation but can hook into the same compiler mechanisms to behave like a union of types

- ad-hoc unions of existing types

Seems more confusing than useful.

Are you suggesting that these design decisions make it through the entire process and into the language without the feature bringing a clear advantage in its use case? What would you say are the worst two or three of these C# features approved in the last decade?

Let’s assume for the sake of argument that you are correct though. The Roslyn compiler diagnostics are second to none, and pretty much any of these features will have corresponding analyzers to help remove some of that confusion, with documentation links being automatically provided if used incorrectly.

These guys aren’t writing feature proposals the way you write comments.

This has been the most requested feature by customers in C# for I-don't-know-how-long now.

Proper type aliases would be nice, but I have to say I really enjoy coding C# these days.

it's hard to think of other major features C# lacks for a language

Heh yeah well, for better or worse, it seems to be C#’s design goal to have every single feature possible, with multiple variations of each of them. It means it’s able to cater to everyone and doesn’t turn people off the way strongly opinionated languages can. But it can make it a bit tricky to pick up.

I’m the author of the original issue — I agree, we’ll have to ensure the struct layout is solved. I think the only thing that makes sense is to just waste a little space and store the fields side-by-side. In almost all cases where people would use a struct I think this is an acceptable tradeoff.

At the point where you have more than 5 cases, the GC overhead starts to get shrink in comparison to the calling convention and copying overhead anyway.

The design is not going to allow for struct layout to have memory safety issues when tearing is involved. That is a problem we are very well aware of and consider in designs.

Tearing issue is mentioned in this issue https://github.com/dotnet/csharplang/issues/7016 but not in proposal

Do note that record types aren't closed even with a private constructor. The compiler will generate a protected constructor for copy operations which can then be inherited from. To prevent this, you have to define your own protected constructor and have it throw a runtime exception if it isn't a valid case.

Not UB, illegal. Per ECMA 335, II.10.7:

It is possible to overlap fields in this way, though offsets occupied by an object reference shall not overlap with offsets occupied by a built-in value type or a part of another object reference.

Per .NET 8.0:

  using System.Runtime.InteropServices;
  var s = new S { Bar = "Baz" };
  [StructLayout(LayoutKind.Explicit)]
  public struct S {
      [FieldOffset(0)] public UInt64 Foo;
      [FieldOffset(0)] public Object Bar;
  }

System.TypeLoadException: Could not load type 'S' from assembly 'foo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' because it contains an object field at offset 0 that is incorrectly aligned or overlapped by a non-object field.

Interestingly, this code elicits a warning

ILC: Method '[foo]Program.<Main>$(string[])' will always throw because: Failed to load type 'S' from assembly 'foo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' because of field offset '0'

from the AOT compiler, but none from the C# compiler.

No - because those aren't limited to just a few specific types.

We added sum types and exhaustive pattern matching in Dart 3.0.

Union types (what the proposal here calls "ad hoc unions") are a separate, much harder feature whose value proposition is less clear. The cost of adding a new kind to the type system is quite large because it impacts method resolution, overriding, type inference, subtyping, least upper bound, generics, type promotion, etc.

It can be worth it (for example, we added tuple/record types in Dart 3.0), but the value proposition must be correspondingly high to justify it. It's not clear that union types meet that bar yet. In many if not most of the places where users are asking for it, it often seems like what they really want is overloading or some other feature.

Mads Torgersen, lead designer of C#, just to clarify lol