[LDM] - Union Types

[mattwar]

The following is a summary of discussions held on discriminated unions in C# by members of the C# language design team. It is not a proposal, and it is not the actual meeting notes.

Union Types

Union types are types where instances represent a single case from a closed set of possible cases.
Each case may carry along additional parameters/data.

Goals for C#

1. Make it possible to consume existing union types in pattern matching.
2. Make it easy to define new union types.
3. Make it easy to define unions of existing types.

State of the Union

There are many existing types that are understood by the language but are not technically closed,
or are closed but are not understood by the language.
Neither can be used with pattern matching today.

Examples of types that C# understands but are not closed

1. An enum is similar to a union type, as the enum defines the set of possible cases
   and (ignoring flags enums) an instance represents just one of the known cases.
   Unfortunately, even though the declaration of an enum is closed, variables of enum type can contain any
   integer value available to the underlying type and thus are not closed.

2. Any C# type hierarchy is similar to a union type, as an abstract base can be considered the union type,
   and the derived types the individual cases.
   Yet, these hierarchies are not closed either as they can only be defined with an unsealed base type.

Examples of types in the wild that are closed, but C# does not understand them.

The types (or similar) are commonly defined and used in functional languages, and exist in many
3rd party libraries for functional style programming in C#.

1. Option<T> -- a type that either has either some value or none.
2. Result<T> -- a type that either has a success with a value or failure with an error message.
3. OneOf<T1, T2, ..> -- a type that can contain an instance of one of a closed set of other types.

Kinds of unions

Type Union

A type union is a union type where the cases are represented by one or more other types.

1. A theoretically closed type hierarchy with an abstract base type is a type union.
   
   Each instance of the type union must be an instance of one of the sub types.
2. The type OneOf<T1, T2, ...> is a type union.
   
   An instance of a OneOf can contain an instance of one of the type parameter types.
3. The type Option<T> is a type union if the implementation depends on and exposes the types Some<T> and None.
4. The type Result<T> is a type union if the implementation depends on and exposes the types Success<T> and Failure.

Tag Union

A tag union is a union type with one or more cases identified by tags and not by types.

1. A theoretically closed enum is a tag union.
2. Option<T> is a tag union if the implementation exposes factories and tests for Some and None, but not as types.
3. Result<T> is a tag union if the implementation exposes factories and tests for Success and Failure, but not as types.

Named Unions

A named union is any union type with an identifiable name that can be used as a type expression like any normal named type in C#.
Likewise, an unnamed union is any union type without an identifiable name,
yet can be instead described by type expression using syntax in a way similar to how C# tuples have syntax but not names.

It is technically possible for both type unions and tag unions to exist in both named and unnamed forms but may not for practicality reasons.
All examples so far have been named, since there does not yet exist a way for them to not have names.

All named union types with different names refer to different types,
while all unnamed union types with the same declaration refer to the same type.

Consuming Existing Union Types

Existing union types are types that already exist or could have been written today,
that could be considered union types but are not yet understood by C# or are not technically closed.

Closing the open types

Enums

The problem with enums not being exhaustive can be solved by allowing them to be sealed, and by following these set of rules.

1. A sealed enum cannot be a flags enum.
2. A sealed enum cannot be implicitly coerced from an integer.
3. A sealed enum explicitly coerced from an integer value not in the closed set raises an exception.

Type Hierarchies

It is possible today to make a closed hierarchy by starting with an abstract base type,
defining all the derived types as nested types within the base type and making the base type's constructor private.
This eliminates the possibility of additional unknown derived types at runtime.
These types of hierarchies could be automatically recognized as exhaustive without additional syntax changes.

An alternative to requiring all case types to be nested, is to instead require an attribute on the type that describes the set of derived types.
This won't guarantee that there will not be additional derived types at runtime, but it may allow the language to have the type behave as if it were,
generating error message for derived types not included in the set and having backup default exception throwing cases auto-generated for all pattern matches.

Describing existing closed union types to C#

In order for C# to understand that an existing type is a union type and use it for pattern matching it must be able to:

1. Identify the closed set of cases for the type, whether tag cases or type cases.
   The compiler would need to know the set of cases to know when a pattern match has been exhausted.

   switch (union)
   {
       case Case1: ...;
       case Case2: ...;
       case Case3: ...;
   }
   

2. Identify which case an instance of the union type is in.
   This would be used whenever C# is doing a type test.

   switch (typeUnion) { case TypeName: ... }
   

   For tag cases, the C# language would have to allow specifying the name of tags instead of just types.

   switch (tagUnion) { case TagName: ... }
   

3. Access the type case instance or tag case parameters (if any).

   switch (typeUnion) { case TypeName t: ... }
   

   For tag cases, the position pattern syntax would be used.

   switch (tagUnion) { case TagName(var p1, var p2): ... }
   

Solutions for this could come in the form of:

1. A fixed set of union types that C# now understands intrinsically.
2. A combination of attributes, common interfaces or patterns within the type's API that declare the case
   and makes it possible to identity them.

Assuming [1] is not the solution, the following requirements have a variety of solutions.

Recognizing the set of cases

1. A type union like OneOf<T1, T2, ...> describes its type cases as type parameters.
   Still, in order to know that the type describes its type cases this way, the type would have to either be known intrinsically by the compiler
   or have a separate attribute or marker interface to inform the compiler that the type cases exist in the type parameters.
2. A type union could declare its fixed cases via an attribute like UnionTypes(typeof(T1), typeof(T2), ...)
3. A pattern in the API, like a property IsXXX for each case XXX.

Testing for cases

Unlike identifying cases, testing for cases requires an actual API on the union type.

1. A tag union could be required to declare a Boolean property IsXXX for each tag case.
2. A type union could be required to declare a Boolean returning method like IsType<T>, or implement an interface that does.
3. A union could have methods with attributes that identity them as tests for cases.

Accessing type case instances or tag case parameters.

1. A type union could declare a method like bool TryGet<T>(out var T value) to both test and return the instance if it matches the type,
   or a method like T Get<T>() accessing the instance with potentially throwing exception when the type does not match.
2. A tag union with case parameters could declare a method bool TryGetXXX(out P1 parameter1, out P2 parameter2).
   
   This would be similar-to/same-as Neal's Active Patterns pattern.
3. At tag union with case parameters could a solution like [2] but use tuples instead of multiple out parameters.
4. A union type could have methods with attributes that identify them as accessors for case values.

C# Union Types

In addition to consuming existing types as union types for the purpose of pattern matching,
it is desirable to have a dedicated C# syntax for describing union types
that automatically produce common boilerplate code and patterns
that have deeper integration and support in C#.

A working syntax for union types

For purposes of discussion of custom union types, this working syntax has been provided.
It is not meant as a proposed syntax for custom union types in C#.

1. Type Unions: union [<name> [<type-parameters>]] '(' <type1> ['|' <type2> ...] ')'

   Examples:
   a. union (string | int)
   b. union StringOrInt (string | int)
   c. union Option<T> (Some<T> | None)
   d. union Result<T> (Success<T> | Failure)

2. Tag Unions: union [<name>] '{' <tag1> [(<parameter1> [',' <parameter2> ...])] [',' <tag2> ...] '}'

   Examples:
   a. union { Yes, No, Maybe }
   b. union YesNoMaybe { Yes, No, Maybe }
   c. union Option<T> { Some(T value), None }
   d. union Result<T> { Success(T value), Failure(string message) }

Note: unnamed union types are possible to describe with this syntax.

Construction

Type unions and tag unions are constructed in different ways.

A type union can be constructed via assignment or coercion from a case type instance.

    union StringOrInt (string | int);
    ...
    StringOrInt stringOrInt = "ABC";

A tag union must be constructed from a factory on the union type.
These factories exist for each tag case.
Factories for tag cases without parameters are represented by a property.

    union YesNoMaybe { Yes, No, Maybe(string reason) };
    ...
    YesNoMaybe x = YesNoMaybe.Yes;
    YesMoMaybe y = YesNoMaybe.Maybe("I'm undecisive");

Testing and Accessing Cases

Type Cases

Type unions expose standard generic methods for testing and accessing types.

    union StringOrInt (string | int);
    StringOrInt soi = "ABC";

    var isString = soi.IsType<string>();
    var tryGetString = soi.TryGet<string>();
    var getString = soi.Get<string>();

Tag Cases

Tag unions expose standard pattern methods for testing and accessing parameters.

    union YesNoMaybe { Yes, No, Maybe(string reason) };
    ...
    YesMoMaybe maybe = YesNoMaybe.Maybe("I'm undecisive");
    bool isMaybe = maybe.IsMaybe;
    bool tryGetMaybe = maybe.TryGetMaybe(out var reason);
    string getMaybeReason = maybe.GetMaybe();

GetXXX() methods for tag cases with a single parameter returns that one parameter value.

GetXXX() methods for tag cases with multiple parameters return a tuple with named elements.

Tag cases without parameters have no Get or TryGet methods.

Type Union Subsets, Assignment and Coercion

Since type unions are declared with a known set of individually addressable types,
it is possible to form additional type unions with a subset of the same types shared by another type union.

    union Animal (Cat | Dog | Bird);
    union CatOrDog (Cat | Dog);

Types Animal and CatOrDog are not the same type, but the can represent some of the same type cases.

Given this knowledge, it is possible to have the language know how to convert between them.

Implicit coercion

A union type can be implicitly coerced to another type union with the same or a superset of the same set of type cases.

    Animal a = catOrDog;

Explicit coercion

A type union with some of the same type cases as another type union can be explicitly coerced.

    CatOrDog cod = (CatOrDog)animal;

Of course, this can lead to a runtime exception if the animal is a Bird.

Coercion API

A type union provides coercion/conversion from other type unions by providing a generic From method that void boxing.
Whenever implicit coercion is identified or explicit coercion is written out via casting, the compiler
implements the coercion by invoking the union type's From method.

    public class MyUnionType
    {
        public static MyUnionType From<TOther>(TOther otherUnionType) where TOther : IUnionType { ... }
    }

Unnamed type unions

It is useful and practical to allow some union types to be referred to via syntax instead of by a type name.
This allows for flexibility in referring to infrequent unions of types without requiring the invention of a name.

Unnamed types have the following qualities:

1. Two declarations of the same unnamed union type refer to the same type at runtime,
   in a similar way to how two anonymous types with the same structure have the same type at runtime.

2. Two declarations of similar unnamed type unions that only differ in order of the declared types
   refer to the same type at runtime.

Unnamed type union example:

    void AddPet(union (Cat | Dog) catOrDog) { ... }

In this example, Cat and Dog are types already defined.
A single API can easily be constrained to either of these types without inventing a name or hierarchy for them to share.
Because you can have instances of both types constructed without reference to the union itself, small unnamed type unions are generally useful.

Unnamed tag union example:

    void AddPet(union { Cat, Dog } catOrDog) { ... }

This declaration while technically possible, may not be useful, since it is not possible to have an instance of either Cat or Dog outside of
the tag union that describes them. Unnamed tag unions are generally more difficult to use than named tag unions.
Even declaring a value of an unnamed tag union is difficult, because everywhere you refer to it you must fully specify the union.

Interdependent type cases

A type union should be described with a set of case types that are all unrelated to each other.

A type union having a case type that is a derived type of another case type may lead to unexpected behavior.
This can either be solved by making it an error at compile-time or by fully defining the behavior.

However, due to possible usage of generics, it may not be possible to always catch these problems at compile time,
so, either type unions must be burdened with additional runtime checks or there should be no
runtime checks for this at all and instead rely on defined behavior.

Example:

    class Animal {}; 
    class Dog : Animal {}:

    union (Animal | Dog) animalOrDog = new Dog();

    if (anmialOrDog is Animal) { ... }

Possible defined behaviors are:

1. Access via a base type is permitted and succeeds when a type union contains a derived type.
2. Access via a base type is not permitted and fails when a type union contains a derived type.

Which behavior is possible hinges entirely on the implementation of the type union, so a choice
here instructs what implementations are possible.

Implementation Choices

Tag Unions

1. The tag union contains an enum field denoting the case and additional fields to represent optional parameters.
   This can be optimized to share parameter fields with common types, similar to how F# generates union types.

2. The tag union is really just a type union and defines individual types to represent case and parameters.

3. A reference type variant of the above choices.

Type Unions

1. The type union is implemented using a family of generic struct wrapper types like OneOf<T1, T2, ..>.
   a. The type contains a single object field and struct types are boxed.
   b. The type contains multiple fields, one for each type.
   c. The type relies on new runtime technology to overlay types in memory.
   d. The same one of the previous choices, plus the type contains an enum field denoting the case.

2. The type union is implemented using a custom code generated struct type specific to the case types specified.
   a. The type contains a single object field and struct types are boxed.
   b. The type contains multiple fields, one for each type.
   c. The type relies on new runtime technology to overlay types in memory.
   d. Same as one of the previous choices, plus the type contains an enum field denoting the case.
   e. The type has an enum field denoting the case, an object field to hold all reference case types
   with a special rule for case types that are record structs
   allowing them to be decomposed into separate parameter fields within the union type that can be
   shared across different cases.

3. The type union is erased to the type object, and all struct types are boxed.
   Information about the set of case types is contained in attributes associated with parameters
   similar to how tuple element names are described in metadata.

4. A reference type variant of the above choices.

Hybrid Unions

With an implementation choice like 2e, it is possible to have a single implementation design serve both type unions and tag unions.
Yet, because the implementation is similar, it would be possible to declare a union type that has both type cases and tag cases.

This may be an alternative to having type unions with singleton type cases.

Improving existing union types outside of pattern matching

Assignment and Coercion

Existing type unions may allow for coercion/conversion between unions of similar type cases,
but they are only checked for correctness at runtime
because defining constraints for when this is possible within the C# type system is impractical.

Any existing type union that allows for coercion must implement a factory, constructor or coercion operators that
consumes a different kind of type union and make runtime checks against the allowed type cases.

C# support for existing type unions can improve on this by adding runtime checks for compatibility when coercion/conversion is used.
The union type itself would still use its own runtime checks regardless, but the API for doing this would need to be standardized
in a fashion similar to the other API's used for pattern matching.

For example, the type union could be required to declare a factory that consumes a common interface for type unions.

    public interface ITypeUnion
    {
        public bool IsType<T>();
        public bool TryGet<T>(out T value);
        public T Get<T>();
    }
    
    ...

    public MyTypeUnion
    {
        public MyTypeUnion From(ITypeUnion otherTypeUnion) { ... }
    }

In this way, any type union instance can be coerced to another type union at runtime,
but also checked for compatibility at compile time.

An non-boxing version

    public MyTypeUnion
    {
        public MyTypeUnion From<TOther>(TOther otherTypeUnion) where TOther: ITypeUnion { ... }
    }

Note: this will not work for tag unions, because even though two different tag unions may have the same named tag,
there is no good way to know that these two tags from two different unions mean the same thing.

Other Topics

Pattern matching with other type unions

It is possible to use pattern matching syntax today to match on multiple types.

    switch (animal)
    {
        case Cat or Dog: ...;
    }

However, someone might now match using a union type expecting similar behavior:

    switch (animal)
    {
        case union (Cat | Dog) catOrDog: ...;
    }

Matching on a union type should be treated as first checking for the union type itself (if the source type is object),
and then attempt matching on the individual types described by the union and converting the result to the specified union type if matched.

Untyped pattern matching

Sometimes the static source type known at the time of pattern matching is only the type object.

This may mean that a union type that ends up getting boxed, will not be recognized as a union type during pattern matching,
and thus type or tag case checks will not be performed, instead only type tests against the (probably boxed) union type.

    var source = (object) catOrDog;
    switch (source)
    {
        case Cat cat: ...;
        case Dog dog: ...;
        default: // oops, neither cat nor dog found.
    }

In order to get at the content of the union type at all, the union type itself would have to be matched first.

    var source = (object) catOrDog;
    switch (source)
    {
        case CatOrDog trueCatOrDog: ...;
            switch (trueCatOrDog)
            {
                case Cat cat: ...;
                case Dog dot: ...;
            }
            break;
    }

But since there are multiple possible type unions that could contain cat or dog, you would potentially have to
check them all.

    var source = (object) catOrDog;
    switch (source)
    {
        case CatOrDog trueCatOrDog: ...;
            switch (trueCatOrDog)
            {
                case Cat cat: ...;
                case Dog dot: ...;
            }
            break;
        case DogOrCat dogOrCat: ...;
            switch (dogOrCat)
            {
                case Cat cat: ...;
                case Dog dot: ...;
            }
            break;
    }

Not knowing the actual union type is problematic.

To solve this we can introduce a common interface for type unions:

    public interface ITypeUnion
    {
        public bool IsType<T>();
        public bool TryGet<T>(out T value);
        public T Get<T>();
    }

If all type unions implement this type, including existing type unions, then instead of the public API
of specific types, a single type test against ITypeUnion can be made.

    var source = (object) catOrDog;
    switch (source)
    {
        case Cat cat: ...;
        case Dog dog: ...;
        default: // nothing ends up here...
    }

Of course, this may lead to an additional problem. If you don't know the source is a type union, it might not be.
Without any additional hints, the compiler must always generate a ITypeUnion case for all untyped pattern matching.

Note: this would not be a problem if the implementation of type unions was either erasure, or the runtime added support for union wrappers to
unwrap when boxed similarly to how Nullable is unwrapped when boxed.

Kicking the Tires

A project exists on GitHub that provides an environment for exploring possible implementations of union types via a source generator.

This is only for the experimenting with the code gen for the types. It does not include any new language syntax or features.

Also, it takes some work to get running.

https://github.com/mattwar/UnionTypes

[FaustVX]

I really like this idea and like many others in this community wanted that for a long time 😄

But I'm asking a question about that sentence:

Two declarations of similar unnamed type unions that only differ in order of the declared types refer to the same type at runtime.

and

The type union is implemented using a family of generic struct wrapper types like OneOf<T1, T2, ..>.

What could happened if in my program I reference Lib1 and Lib2.
Lib1 contains union CatOrDog (Cat | Dog), so compiled to OneOf<Cat, Dog>.
Lib2 contains union DogOrCat (Dog | Cat), so compiled to OneOf<Dog, Cat>.

Will this be possible (I hope it will):

CatOrDog c = new Cat();
DogOrCat d = c;

[mattwar]

That is kind of a stretch goal. You can imagine that the compiler might choose an order of the types, instead of using the explicit order typed. It might not work out.

For your second part, yes implicit coercion between different but compatible types would exist.

[agocke]

The bigger problem is probably something like

(A|B) x = ...;
(A|B|C) y = x;

Yes, you can define a conversion here, but there are places that won't work, e.g. there can't be a conversion from IEnumerable<(A|B)> to IEnumerable<(A|B|C)>.

[orthoxerox]

Do type unions even need proper names, or can we make do with aliases, like in C? global using CatOrDog = union (Cat | Dog); The only reason why a proper name can be useful is generics, since generic aliases are not a thing.

I'm honestly more excited about sealing/closing existing enums and type hierarchies. Triggering that case _: throw new Exception("You didn't fix this switch statement after adding another type, doofus"); has become too common after I migrated to a more functional style of C# and I would love this to be a compile-time error instead.

[mattwar]

I think for the case where a named type union is implemented as a set of OneOf<...> types, then type aliasing is better than naming via derivation. If a named type union is instead implemented as a separate generated type specific to the set of type cases (similar to tag union implementation) then the type having the name you've specified is probably better.

[iam3yal]

I'm not sure whether I missed that but would it be possible to do something like this:

// Inheritance
public sealed class A : B | C
{
}

// Composition
public sealed class D
{
    public D(B | C bOrC)
    {
    }
}

var a = new A();
B b = a;
C c = a;
var d1 = new D(a);
var d2 = new D(b | c);

In the following case does the keyword union really necessary? the compiler knows that animal is a union (or not?) and you also noted that tag unions can't be flags.

switch (animal)
{
    case union (Cat | Dog) catOrDog: ...;
}

[Richiban]

I believe the union keyword is just working syntax; they'll design the functionality of the feature first and then the syntax. They just need to throw a written form together to be able to discuss how the feature should work; working syntaxes work best when they stand out, hence the keyword.

[CyrusNajmabadi]

I believe the union keyword is just working syntax; they'll design the functionality of the feature first and then the syntax.

Correct. We need a way to talk about the different forms without confusion. So this is temporary syntax that allows for that.

[iam3yal]

Thank you. 😃

[obiwanjacobi]

What if B and/or C are sealed in class A : B | C?
I don't think of a union type as a case of inheritance (that's just me).

[FaustVX]

Unnamed tag union example:

void AddPet(union { Cat, Dog } catOrDog) { ... }

This declaration while technically possible, may not be useful, since it is not possible to have an instance of either Cat or Dog outside of the tag union that describes them. Unnamed tag unions are generally more difficult to use than named tag unions. Even declaring a value of an unnamed tag union is difficult, because everywhere you refer to it you must fully specify the union.

This could works if the proposal (can't find it) to omit the containing type is accepted :

void AddPet(union { Cat, Dog } catOrDog) { ... }

AddPet(.Cat);

[mattwar]

There is a proposal for a feature that will allow you to only need to specify the name of an enum member if the name binds to a member of the target type. That might work in this case (possibly modified to include all static members.)

Though, if the name bound to anything else in scope first, you would still have to fully qualify the member and that would get annoying.

[FaustVX]

That's the proposal I referred to.

Though, if the name bound to anything else in scope first, you would still have to fully qualify the member

But yes, I didn't think of that.

Of course, it was just an idea, it's weird to have to use that proposal feature.

[HaloFour]

This is awesome stuff, and a lot of it. Is the intent to explore each of the different forms of unions to land on which variation(s) offer the best bang for the buck or is there interest in bringing all of these forms of unions to the language (and runtime in some cases)?

It's mentioned that common DUs like Option<T> and Result<T> could be implemented as either type or tagged unions, but how would the former work as a low-cost abstraction? Does that mean that such a union would be a type hierarchy, perhaps a set of structs that implement a common interface? If so, would that mean that allocations/boxing couldn't be avoided? IMO that's probably the biggest implementation detail that could impact how such unions would need to be defined.

[mattwar]

The tag union form could be implemented to avoid allocation/boxing without needing runtime help.

[HaloFour]

@mattwar

The tag union form could be implemented to avoid allocation/boxing without needing runtime help.

Agreed. When we've chatted about DUs in Discord/Gitter before I think we broke them down into reference DUs, which would be closed type hierarchies, and value DUs, which would be tagged unions. So, I guess in reference to this summary, you can define Option<T>/Result<T> as type unions, but it wouldn't be the efficient way to do so.

[sab39]

What if, instead of using an ITypedUnion interface with generic methods for IsType, TryGet and Get, it were instead a generic interface:

interface ITypedUnion<T>
{
  bool IsType { get; }
  bool TryGet(out T result);
  T Get();
}

Then OneOf<T1, T2> could implement both ITypedUnion<T1> and ITypedUnion<T2> and implement From using something like obj is ITypedUnion<T1> t1 && t1.TryGet(out var result).

[HaloFour]

OneOf<T1, T2> couldn't implement ITypedUnion<T> twice like that:

error CS0695: 'OneOf<T1, T2>' cannot implement both 'ITypedUnion<T1>' and 'ITypedUnion<T2>' because they may unify for some type parameter substitutions

[sab39]

Sure, but as we're talking about a language feature, couldn't the compiler override that? After all, we know that the parameters can't unify, because union (string | string) makes no sense in the first place. I'd imagine that OneOf<string, string> would do weird things already...

[mattwar]

OneOf<string, string> should work perfectly fine. This is the only way to have it work correctly when constructed under generic contexts when you don't know explicitly what the types are.

[orthoxerox]

I would expect union (string | string) to be equivalent to just string. At the very least, I will be understanding if an instance of this union reports it's an instance of both variants. I would totally use tags if I wanted to distinguish between two different kinds of strings: union Response { Success(string id), Failure(string message) }.

[Richiban]

I have to say this is one of the most exciting topics I've seen on the development of C# for ages! I really hope it goes somewhere good :)

[DavidArno]

I love this. I'd go one step further than @Richiban and say that this is in the top two most exciting C# developments in years (the other being related: pattern matching of course)

A couple of thoughts, one irreverent and one serious:

Firstly, regarding the line CatOrDog cod, I can't help it but I instantly thought, "no it's not; it's a fish". Sorry 😊

Much more seriously, I've concerns over the idea of type and tag unions being seen as different to each other. Consider the following code:

record Dog;
union CatOrDog { Cat, Dog }
union CatDogOrNumber ( Cat, Dog, int )

CatAndDog is a tag union. So is the Dog tag different here to the Dog type above? Or are they the same? Does Cat get defined as a new type?

CatDogOrNumber is a type union, but I've not explicitly defined a Cat type. So would it fail to build? Alterntaively, will it invent a CatDogOrNumber .Cat type? Or would it use the type defined via CatOrDog in order to re-used types between unions allowing implicit casting?

And what happens with assignment here:

CatOrDog dog1 = new Dog(); // Allowed?
CatOrDog dog2 = CatOrDog.Dog; // Or will only this work?

CatDogOrNumber cat1 = new Cat(); // Will this work?
CatDogOrNumber cat2 = new CatDogOrNumber.Cat(); // Or will it work like this?

cat2 = dog2; // Can I implicitly cast between tag and type unions?

[Richiban]

I see the bit you're referring to now; although the implementation would allow for for it in that case (2e) I don't think the syntax allows for it. It would be very confusing if union CatOrDog { Cat, Dog } did different things depending on whether types called Cat and/or Dog happened to be in scope at the time the union was declared. You'd need to differentiate somehow with the syntax, with union CatOrDog { Cat, new Dog } or something.

[DavidArno]

Yep, something like that might be needed. Lots of things for @mattwar and the team to ponder here. Really looking forward to seeing how this evolves.

I'm also intrigued by the line "This would be similar-to/same-as Neal's Active Patterns pattern." The idea that an implementation of unions could lead to a solution to active patterns at the same time is seriously super exciting 😃

[Richiban]

Yes! Related: implicit and explicit extensions (née roles / extensions) have been proposed as a sort of solution to active patterns too.

[orthoxerox]

I agree that it would be very confusing and I don't see a use case for it, unlike all other options:

1. sealed enums: just like regular enums, but with compile-time safety
2. closed type hierarchies: just like existing type hierarchies, but with compile-time safety
3. type unions: ad-hoc unions of types you can't be bothered to come up with a name and/or wrappers with
4. tag unions: efficient hierarchies of value types that are more complex than a sealed enum
5. mixed type/tag unions:

• tag unions where some tags are self-describing
• type unions you want to add a singleton to

However, a mixed type/tag union can always be expressed as a tag union or a type union: union ConnectionString { string, IDictionary<string, string>, InMemory } is not that different from union ConnectionString { Literal(string value), Properties(IDictionary<string, string> props), InMemory } or record struct InMemory; union ConnectionString(string | IDictionary<string, string> | InMemory).

[mattwar]

The working syntax provided has no way to make a hybrid type/tag union. The tags in a tag union cannot be shared across separate union declarations. The types in a type union can. They are not defined by the type union syntax, only referenced. The examples assume the types are declared elsewhere. The intuition is supposed to be that the braces in the union syntax denotes declaration of members, while the parentheses in the type union only allows for reference.

[DavidArno]

Thanks for the clarifications, Matt.

I agree with your intuition regarding {} versus (). Parentheses look like a record declaration, ie I'm passing existing things into it. So that's for types. The braces are for eg a type declaration so the things in it are new to that type and so are tags. I'm unsure how intuitive that will be for the wider audience (and it is only a working syntax so obviously could change) but it works for me.

Not that I'm prone to changing my mind on a whim, but in the space of an hour I've completely changed my mind on this. I'd love to see the union (string | int) syntax dropped in favour of just expressing it as unnamed ah-hoc type unions: string | int. Naming them would then be solved via aliases, requiring #1239 to be implemented for generic aliases to handle eg using Option<T> = Some<T> | None;

My initial reaction to the two types of union was negative: it overcomplicates things and let's aim for one hybrid union style. But as I've thought through examples, I think they serve quite different purposes so keeping them separate makes sense.

Most examples I an think of can be expressed as tag unions. The one clear example for me for type unions is for avoiding the need for interfaces when dealing with related structs, eg rather than structs Point, Circle, Rectangle all implementing IShape, they can belong to union Shape(Point, Circle, Rectangle). It'll be interesting to see if there's really a need for type unions beyond another way of expressing a type hierarchy and therefore whether they survive as a separate concept through to release. All good stuff.

[mattwar]

The syntax in the document is not a proposed syntax for C#. It is just there so the working group can have a syntax to use when talking about union types semantics without rat-holing on syntax issues. I'm sure everyone one in the group would rather have a type union syntax be: A | B or more likely (A | B), though we have not yet explored on how to make such a syntax not be ambiguous in the language.

[Richiban]

FWIW, I'd rather the "existing type" union (working syntax: union StringOrInt(string | int)) was usable only in a type position:

public void M(union (string | int) arg)
{
    ...
}

And then we could combine it with proper type aliases as a feature if you want to be able to reuse it:

type UserIdentifier = union (UserId | EmailAddress);

// or, more C#-y

global using UserIdentifier = union (UserId | EmailAddress);

That would save "union declarations" specifically for a declaration of new types or cases/tags:

union Shape
{
    Circle(int radius), Rectangle(int width, int height)
}

Edit: Square -> Rectangle

[DavidArno]

One thing I hope we end up with is your first example being able to be expressed as:

public void M(string | int arg)
{
    ...
}

It's obvious it's a choice between types and the union () ceremony really only wants to be there if needed by the compiler. It adds nothing but noise for the reader in my view and has the advantage that it makes the distinction between an ad-hoc union of types and a tag union very distinct.

Decoy snail Generic unions.

Solved by #1239:

global using Option<T> = Some<T> | None; 

[DavidArno]

Square(int width, int height)

Shape ohDear = Shape.Square(2, 3); 😝 😆

[Richiban]

Square(int width, int height)

Shape ohDear = Shape.Square(2, 3); 😝 😆

Lol, I obviously meant Rectangle :P

[R2D221]

public void M(string | int arg)

Also, why not public void M((string or int) arg), to keep it consistent with existing pattern matching syntax?

[CyrusNajmabadi]

No real syntax is being discussed right now. The syntax presented is just a way to clearly distinguish the concepts. Syntax will come later.

[DavidArno]

What's the current thoughts on unions and generic type constraints. Will something like this work?

record class Dog;
record struct Cat;
union DogOrCat(Dog, Cat);
class Pet<T> where T : DogOrCat { ... }

var cat = new Pet<Cat>();
var dog = new Pet<Dog>();

[mattwar]

There is a whole space of union types intersecting with generic type parameters that is not yet explored. Though it would be very complicated to invent a solution that allows for union types in type constraints like this since that would involve the runtime directly understanding them and not just C#.

[Nairda015]

What about this case:
1:

record Cat;
record Dog;
record Fish;
union Mammal ( Cat | Dog );
union Animal ( Mammal | Dog | Fish ); // is adding both Mammal and Dog valid?

Animal animal = new Dog(); 
if ( animal is Mammal ) // will it return true?

[mattwar]

This is a good topic that was actually discussed and should have been in the document, but I forgot to add. It is another case of it works well when the compiler knows the static types and can sort out the meaning of the type union but works less well when the types are generic type parameters specified in a generic context. I'd prefer that it worked, so I'm willing to find a solution.

[R2D221]

Regarding the topic “Untyped pattern matching”, I think that they should be treated in a similar way to Nullable. That is, that you can never box a Nullable and if you do object x = (int?)5 the boxing algorithm actually stores the underlying value.

This way, if you have code like this, you don't risk having a union under the hood.

var source = (object)catOrDog;
switch (source)
{
    case Cat cat: ...;
    case Dog dog: ...;
    case CatOrDog x: // impossible: unions are never boxed. Only the underlying value is boxed.
}

---

Another experiment that I've been doing in my own, but one that I know is a horrible hack, is to define a OneOf<T1, T2> interface, but assign them with Unsafe.As. Like this:

var catOrDog = Unsafe.As<OneOf<Cat, Dog>>(cat);
catOrDog = Unsafe.As<OneOf<Cat, Dog>>(dog);

switch ((object)catOrDog) // casting back to object because the compiler knows neither type implements the interface
{
    case Cat cat: ...;
    case Dog dog: ...;
    case Mouse mouse: // this works because nothing is actually validated
}

What I want to show from my example is that type unions should exist as return types and field types, but never as the actual type of an instance. There is no logic in creating a CatOrDog instance when we are dealing with individual cats and dogs, and not an instance that can turn into a cat or a dog.

[mattwar]

There are a lot of trade-offs to consider for how a type union is represented. If there is no actual CatOrDog type at runtime, then you've basically chosen the erasure solution outlined in the document, and it is instead typed as object. Then the problem becomes how to represent the union definition if it's not actually part of the runtime type.

[R2D221]

The way I'm imagining is for it to be like interface types. You don't type erase interface types: if a property or method returns an interface, the interface type still exists in runtime code. But an instance itself will never be of an interface type. That is, obj.GetType() will never return an interface type.

If I understand correctly, that wouldn't be type erasure, BUT, it would require substantial changes to the type system to implicitly say that “Cat implements the CatOrDog union type even if that's not declared in the type itself”.

[jzabroski]

Awesome proposal. I would like to highlight a related issue that would make this feature gangbusters: #3723

In particular, I would like to await a union rather than a Task (similar to the zio library in Scala and it's ZIO[R, E, A] type), and get rid of the dreadful Task Parallel Library semantics. Quoting the zio website for ZIO[R, E, A] for those unfamiliar of how zio uses unions:

The ZIO[R, E, A] data type has three type parameters:

R - Environment Type. The effect requires an environment of type R. If this type parameter is Any, it means the effect has no requirements, because you can run the effect with any value (for example, the unit value ()).
E - Failure Type. The effect may fail with a value of type E. Some applications will use Throwable. If this type parameter is Nothing, it means the effect cannot fail, because there are no values of type Nothing.
A - Success Type. The effect may succeed with a value of type A. If this type parameter is Unit, it means the effect produces no useful information, while if it is Nothing, it means the effect runs forever (or until failure).

Further, they note that the .NET Task type is really just a special case in this model:

Type Aliases

The ZIO data type is the only effect type in ZIO. However, there are a family of type aliases and companion objects that simplify common cases:
<snip />
Task[A] — This is a type alias for ZIO[Any, Throwable, A], which represents an effect that has no requirements, and may fail with a Throwable value, or succeed with an A.

This should really make it obvious where the direction of C# should go in terms of improving concurrent, parallel library design!

[AnthonyLloyd]

This would open up other areas as well e.g. more expressive unit testing combining async, test data, multiple asserts and logging.

[jzabroski]

Yes, to put it bluntly, ZIO Test does have far more expressive unit testing than xunit: In xunit, Assert can (implicitly) only hold a single result. Ideally, xunit Assert would work like ZIO Test Assertion and have a tree-like structure where a set of assertions are composed from Or, And, Any and All operators. It would also be a lot easier to reason about Failure, as xunit currently requires capturing a side effect via Assert.Throws<TException>. Additionally, because this model of parallelism "holds the future", when code is in a failed state, it can be queried to know what success state action would have been taken if the code did not fail; something .NET cannot do and instead generates AggregateException or UnobservedTaskException. In other words, even better than Ben Adams' pretty stacktrace demystifier, would be to be told exactly where in the code things went from a success to failure. - Solve the problem, by avoiding it. No more looking at complicated async state machine stack traces.

[agocke]

Turns out I ended up exploring a very similar space in #7016

My conclusion is that it's hard to make so-called "type unions" in this proposal work efficiently, meaning the fewest allocations and expensive conversions. My preference is that we would start with "tagged unions," which I think can meet our requirements for the highest perf scenarios. I would be pretty disappointed if we implemented a feature that couldn't be used in common locations because it was too costly.

[jzabroski]

Is the reason type unions don't work efficiently because there is no intrinsic TypeSwitch CIL instruction to dispatch on?

[agocke]

No, as I outlined in the issue, because each variant would be a different underlying type, subtyping would mean that you have to convert by doing N type checks.

Basically, A|B|C is not the same type as C|A|B, and A|B isn't a subtype of either of those. So you have to introduce potentially expensive conversions.

Also, there's just fundamentally no way to efficiently represent OneOf without boxing to object right now. The CLR would have to offer built-in specialization of OneOf -- and it's an open question what the runtime could do here.

[Meigs2]

Has there been any discussion surrounding nullability restriction/enforcement?

For example if we have the following union definition:

class Dog {};
class Cat {};

union DogOrCat (Dog | Cat);

From my understanding, for union types to be truly closed, there has to either be an enforcement that a value is an instance of a Dog or Cat and nothing else. But, what's stopping me from declaring the following:

DogOrCat value = null;

If this is possible then the union DogOrCat is actually implicitly defined as:

union DogOrCat(Dog | Cat | null);

In my mind, if you declare a union and you do not specify null as a possibility, the union should never be a null. However, I can easily imagine a scenario where you declare a union as such using a class from a 3rd party library:

union 3rdPartyOrDog (3rdPartyType | Dog);

3rdPartyOrDog result = 3rdPartyLibrary.Get() // returns either 3rdPartyType or null

Because 3rdPartyOrDog does not declare null as a possibility, I feel like the runtime would have to throw an exception at runtime or prevent the compilation of the code (if nullable reference types is enabled), like so:

union 3rdPartyOrDog (3rdParty | Dog);

3rdPartyOrDog result = 3rdPartyLibrary.Get()
//^^^^^^^^^^^ Invalid assignment, 3rdPartyLibrary.Get() returns a nullable value and 3rdPartyOrDog does not
              declare `null` as a valid type within the union definition.

My initial thinking would be that the error would have to be resolved at compile time in order to have unions be truly closed, and the preceding issue could be resolved in one of the following ways:

// re-define the union type to accept null values like so:
union 3rdPartyOrDog (3rdPartyType | Dog | null);
// or set the result type nullable, which is equivalent to the above, only locally.
3rdPartyOrDog? result = 3rdPartyLibrary.Get()

[jzabroski]

The proposal in this document is to erase the Union type at run-time. Thus, a hole in this proposal is that unions can accept run-time values of null. In this scenario, converting an object to a Union would be done via:

Unsafe.As<OneOf<Cat, Dog>>(3rdPartyLibrary.Get())

However, it is valid point that the original document speaks of closed unions, but does not explicitly state DogOrCat value = null; is invalid.

[mattwar]

To clarify, there was no actual proposal in this document. It has some implementation options enumerated, and erasure was one of them. This subject is still an ongoing discussion, and the document was only a summary of discussions held so far as a report back to the full LDM team.

[evgenxpp]

omg, take my money and give me discriminated union asap. really love to see more and more rust lang like features in c#. OneOf is great, but better to have a native support to be able to leverage Result<T,E> and Option within switch expression

[AnthonyLloyd]

I find nullable enable much better than Option<T> as used in F# because once you've checked for null then the compiler knows for the remaining code.
F# has an issue with code with multiple Result/Option mapping looking quite ugly.
If this smart casting could be considered for Result, OneOf etc it could reduce the friction of using these types.

[jzabroski]

Can you give your actual code?

It's a lot of code to implement the data type Maybe = Just a' | Error | Nothing. I have not written this code in about a decade since I worked on teams that did not like it.

However, for any code that can fail, it is trivial to "Wrap" that code in something returns Maybe instead. Since LINQ supports monads via the iterator interface, you can simply make sure you trap what happens when something is DefaultOrEmpty by converting that default (null for reference types) into Nothing. Then you have methods that operate on Nothing. Or methods that operate on Error. So you trap the exception once and deal with it via generic exception handlers.

[CyrusNajmabadi]

I don't know what this means. How would this work if i currently have a boolean returning (or exception throwing) predicate that i'm using with .Where, but now i change that predicate function to return a Result<bool, SomeError>?

You said:

I fear you grossly misunderstood his point. Result<T, TError> is the solution, not the problem.

I'm trying to understand how it is the solution, using a pretty simple use case. Could you just show how this would work for the case i outlined above? thanks! :)

[DavidArno]

I don't know what this means. How would this work if i currently have a boolean returning (or exception throwing) predicate that i'm using with .Where, but now i change that predicate function to return a Result<bool, SomeError>?

You said:

I fear you grossly misunderstood his point. Result<T, TError> is the solution, not the problem.

I'm trying to understand how it is the solution, using a pretty simple use case. Could you just show how this would work for the case i outlined above? thanks! :)

Hi @CyrusNajmabadi,

I think you missed where I gave an example of how this might work, by having the concept of try <expression> within the language, which lowers to code that invokes the expression, catches any (sensible to catch) exceptions and returns a Result<T, Exception>, where T is the type of the expression. It could then be used with Where with something like:

var listOfNullableInts = GetSomeLIst();
var onesAndTwos = listOfNullableInts.Where(x => (try int.Parse(x)) is int i && i is 1 or 2);

Obviously Where still returns bool (that can't change), but the language provides a simple way of leveraging Result<bool, Exception> within the predicate code.

[CyrusNajmabadi]

Gotcha. I wasn't understanding that he was saying that Result<,> appropriate (with ergonomic language constructs) for allowing explicit errors as part of signatures when desirable, but also bridging to non-explicit forms when not.

Seems a reasonable position to me. Not sure if this would end up being highly annoying in practice or not though. Would have to see how it would work out in the existing ecosystem.

[jzabroski]

@HaloFour

I'm not sure what you mean by that statement. The versioning problem still exists, in that you cannot add another exception type to the list of possible exceptions without breaking every single consumer. In this case it's so much worse as the exceptions are a part of the method signature, so no existing consumer can call that method unless it's updated.

There is an extensibility problem, in that if you want to extend a data type to support more cases without compilation. (Extensibility problem is also known by its dual name, the Expression Problem).

To me, versioning problem (as I read Anders describe in his interview) describes a problem where client callers break because they are on the wrong version of the code, which can happen in Java when a library API adds a checked exception, and the caller is not updated. You can encode the versioning problem as an extensibility problem, but you don't have to. The other half of the versioning problem, from what I gleaned about Anders description, is the tendency for people to have empty catch blocks and not properly unwind changes to the heap via finally - e.g., if you have a 30M line code base and some super generic System namespace library function that is used everywhere, then people may just add empty catch blocks to get the code to even compile (so they can see what other errors there are besides this one contract change, and if the tests still pass). You can still sub-type Error instead of union'ing all the possible failures as a contract. That's actually how ZIO works btw - it's just Throwable.

John de Goes actually has several talks about the sweet spot of API design. He actually talks about how Actor Model is on the other end of the spectrum (surfacing an Any type) and generally not useful as an API because its so liberal as to describe nothing contractually. I highly recommend a Saturday binge watch of some of his talks.

[orthoxerox]

Will type unions support generic constraints? If I have Foo<T> where T : Bar, will (DerivedBar | AnotherDerivedBar) work as T?

I've just realized that this would be required to have Result<T> be something better than a worse Exception alternative. For example, if the tagged type union is defined as union Result<T, E> where E : Exception { Success(T value), Failure(E exception) }, then type unions will be necessary for a sensible emulation of "checked exceptions":

static IEnumerable<TResult> SelectMany<TSource,TCollection,TResult> (
    this IEnumerable<TSource> source,
    Func<TSource,IEnumerable<TCollection>> collectionSelector,
    Func<TSource,TCollection,TResult> resultSelector);

becomes

static Result<IEnumerable<TResult>,(TCollectionEx|TResultEx)> SelectMany<TSource,TCollection,TResult,TCollectionEx,TResultEx> (
    this IEnumerable<TSource> source,
    Func<TSource,Result<IEnumerable<TCollection>,TCollectionEx>> collectionSelector,
    Func<TSource,TCollection,Result<TResult,TResultEx>> resultSelector)
    where TCollectionEx : Exception, TResultEx : Exception;

allowing you to track which exceptions can be returned via the Failure tag.

[danielwcarey]

I sat down several months ago and tried to write an example C# code snippet based on some of the JavaScript audio processing API's I was looking at. I'm not a language designer and approached the syntax with the idea, "can I re-use the existing C# pattern matching syntax to introduce 'union/discriminated union types'". What I wanted was a way to use the syntax used in pattern matching to also be the syntax used for declaration.

Here is what I wrote as a rough/naive example, based on the idea that Type should be thought of as List.
Hope it might help...

void Main() { 
   var sample1 = new Sample1<pattern1>{ 
      AudioStream = 22.5f, 
   }; 
   sample1.PlayStream(); 
} 

public interface IAudioStream { 
   void Play(); 
} 

// Declare new union types sample 1 
public Type pattern1 = bool or IAudioStream or float; 

// Declare complex union types 
public Type pattern2 = 
   bool B or 
   IAudioStream Stream or 
   X where X: float or double; 

public class Sample1<T> { 
    
   public class Sample1<T> where T: bool or IAudioStream { 
   } 

   // AudioStream : object 
   private object _audioStream = false; 

   public object AudioStream 
   { 
      get => _audioStream; 
      set 
      { 
         if (value is bool or IAudioStream or T) // if (value is pattern1) 
            _audioStream = value; 
         else 
            throw new Exception($"Invalid type assignment: {value.GetType().Name}"); 
      } 
   } 

   // AudioStream2 
   public T AudioStream2 where T: A or bool or IAudioStream { get; set; } 
    
   // AudioStream3 
   private T _audioStream3 where T: A or bool or IAudioStream; 
    
   public TAudioStream3 where T: A or bool or IAudioStream { 
      get => _audioStream3; 
      set { 
         _audioStream3 = value; 
      } 
   } 
    
   public void PlayStream() 
   { 
      if (this.AudioStream is IAudioStream s) 
      { 
         s.Play(); 
      } 
   } 
}

[Eirenarch]

Would it be possible that when the compiler sees an union type the if (variable is SomeType) statement narrows the type of the variable in the if block. I know that it normally doesn't work because of legacy code with overloads but the code with unions will be new code, maybe that can sneak in

[mattwar]

You would be able to use the normal pattern matching ability to introduce a new name:

if (variable is SomeType newName) ...

newName would have the type SomeType.

[ziaulhasanhamim]

Rust enum can be considered as the best implementation of union that is implementable in C#. Which doesn't allocate any extra memory and doesn't allocate on the heap.

The type union is implemented using a family of generic struct wrapper types like OneOf<T1, T2, ..>.
a. The type contains a single object field and struct types are boxed.
b. The type contains multiple fields, one for each type.
c. The type relies on new runtime technology to overlay types in memory.
d. The same one of the previous choices, plus the type contains an enum field denoting the case.

Here,
a. It would cost a lot of heap allocation even for small fields and we all know boxing is really slow.
b. It would allocate extra memory.
c, d are almost the same. They will provide the best value. Pretty similar to rust.

So my preference would be,
c or d > b > a

[AartBluestoke]

the problem with c,d means that you could not safely run the newly compiled code on an old runtime unless it can be expressed as legacy 'unsafe' code with tags that allows a modern jit/runtime to more efficiently process.
for dotnet this has basically always been true:

• old code can be compiled with any newer compiler.
• code from newer language versions and newer compilers can run on any older runtime (back to 3.5 or perhaps even earlier)

[Joe4evr]

• code from newer language versions and newer compilers can run on any older runtime (back to 3.5 or perhaps even earlier)

That's not true anymore. The language and runtime version in lockstep these days, and running code compiled under a newer language version on older runtimes is explicitly unsupported by Microsoft.

[JaggerJo]

Unions would be really nice 👍 Coming from F# I miss them daily when writing C#.

[erik-kallen]

Glad to see that this is finally getting some attention!

Would it be possible to get some runtime support (analogous to Nullable<T>) for Option<T>?

[erik-kallen]

Though perhaps it would be enough to just define it as

struct Option<T> where T : notnull
{
    private T? value;
    public bool IsSome => value != null;
    ....
}

[tuscen]

It would be great to have, but I think the ship has sailed. It would be ambiguous to have the same syntax to represent different nullable type so we’re stuck with whatever we have now.

[erik-kallen]

What do you mean? I don't want T? to mean Option<T>, I just want some way so we don't need to handle both null and None if we have an Option<T> (looking at you, Scala)

[CyrusNajmabadi]

I just want some way so we don't need to handle both null and None if we have an Option (looking at you, Scala)

Use a struct. Now you don't have to deal with null.

[erik-kallen]

Yes, I realized that. But perhaps special boxing rules (like Nullable) would be useful? Not sure about it, but I think it should be considered.

[joclegg]

Would this proposal support something like typescript's Exclude? Just thinking it would be useful to be able to remove one type from an existing union.

[tuscen]

I don’t think so. Typescript can do a lot of programming on top of types partially because its type system is structural, but in C# it’s nominal, i.e. the actual type is important and not its structure.

[johnazariah]

Check out https://johnazariah.github.io/csharp-uniontypes/tutorial.html#constrained-types :)

[caseee]

Is also considered produce/consume model using openapi OneOf?

[johnazariah]

This is such a long-awaited feature of C# for me. Thank you for proposing this.

In fact, I've had multiple "union" implementations to do this since 2015 or so - but they never had the elegance of being part of the language.

The latest incarnation of my clunky solution is a source-generator which pretty much generates exactly what is proposed [here] (https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md#implementation). If anyone is interested, the source generator is here

[huoyaoyuan]

I've read through the latest type union proposal. I like the multi-category approach to provide viable solutions for different scenarios. I have faced the exact situation of "I wish I could use unions in my graphics pipeline".

There are some words and suggestions, mostly for Ad Hoc unions:

• Can Ad Hoc unions be lowered to common base type, for example (Dog or Cat) becoming Animal. This matches some cases the developers are already using, and enables access to base type members.
  • With interfaces, there can be more than one potential common type. Can best common type rule be used to determine it?
  • Can there be a syntax to explicitly specify the lowered common type? It may be too verbose and unsuitable for Ad Hoc definition.
• Can Ad Hoc unions be explicitly declared and encoded in metadata?
  • This is somehow the same with declared delegate type: getting encoded in metadata, can declare more detailed information like parameter name, but loses interchangeability of equivalent type. This can be a fair trade-off.
  • Or, it can be a metadata-only information to write down the alias name and lowered type. With a sample syntax union CatOrDog(Cat or Dog) : Animal;, it encodes an Ad Hoc union of Cat or Dog with alias CatOrDog and lowered as Animal.

Honestly I'm a fan of generics. However, using dedicated generic type can cause more and more problem when using as generic argument into another generic type. This can only be solved with full runtime support. It's currently not critical for union types, but we may have to deal with it for (Interface1 and Interface2).

[hez2010]

Can Ad Hoc unions be lowered to common base type

IMO ad-hoc unions should never have a common base type, but implementing an interface like IUnionType would be great. This would allow us to do pattern matching (and type testing) on generic types with IUnionType constraint.

[huoyaoyuan]

IMO ad-hoc unions should never have a common base type, but implementing an interface like IUnionType would be great.

I'm not meaning the common base type of different Ad Hoc unions. I mean the common type of the members of one union.

[hez2010]

the common type of the members of one union

Yeah, I know. But it is still incorrect as ad-hoc union types shouldn't follow subtyping.

[Joe4evr]

• This is more of an API thing, but regarding the proposed union types to be exposed with the feature: If there's going to be a Result<TValue, TError>, then please also consider having it partnered with Result<TError> (effectively "void"-Result).

• In the Q&A section, the answer to "why is Option needed?" could be expanded with something along the lines of:

It's also useful for domains where there is a semantic difference between a value specified as null and not specified at all. This kind of semantic is not possible to model with just the type system's null alone.

• Since I don't see it explicitly mentioned: Can users also declare "regular" APIs in unions aside from case members? Would be useful.

[colejohnson66]

I'd much rather see the () ("unit") proposal (#1604) succeed. Then, Result<TValue, TError> would become Result<(), TError> like Rust.

[mattwar]

There is now a proposal for Type Unions as mentioned by @johnazariah, here:
https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md

I've created a separate discussion for it here:
#8313