[LDM] - Type Unions Proposal

[mattwar]

The discussion for the accepted unions proposal is here: #9663
Issue: #9662

The following discussion is related to an older proposal that was not accepted by the LDM.
Type Unions in C#

[jaredpar]

Union classes are considered exhaustive. If all member types are accounted for in a switch expression or statement, no default case is needed.

Don't see how this is possible. If the union type is defined in a different assembly there always has to be a default block in a switch. Perhaps it's compiler generated not user written but it still needs to be there.

[ilmax]

Will a default be forbidden in a switch on unions? It would be nice not to be allowed to opt out of exhaustivness checking with DU

[Joe4evr]

@ilmax I assume there'll be a compiler warning if it sees missing cases and no default. Anything beyond that is pretty likely out-of-scope, but you can always write a custom analyzer to force your consumers to do (or not do) something when they use your types.

[mattwar]

You are only allowed to not have a default if you've handled all cases, otherwise you must still have a default. You can still have a default even when you have covered all cases.

[rgbav]

can someone please explain why it could be problematic when the union type is defined in a different assembly?

[snarbies]

I would imagine because the different assembly could change. If your own assembly changes, it will be recompiled. Exhaustiveness checking can easily be validated. If a referenced assembly is updated, other assemblies still need to be able to load and execute it, which means you need a default case to handle previously non-existent cases.

[R2D221]

For ad hoc unions, will stuff like (Cat or Dog) animal be compiled to object animal even if both Cat and Dog inherit from Animal? What if I want to call methods on it, like animal.Eat()?

[jaredpar]

Can we make the method/etc. signatures use object, but auto-emit Unsafe.As<> as needed, and just do the most common type for locals? That way, we get the benefit of the cleaner syntax without binary compat problems.

I'm sure there are a few cases where we could do this but I'm skeptical it's worth the investment.

[TahirAhmadov]

I'm sure there are a few cases where we could do this but I'm skeptical it's worth the investment.

In terms of reducing the cost here, why not just go with the Unsafe.As<> approach across the board? It becomes a simple rule and a simple implementation.

[jaredpar]

Using Unsafe members in generated code is not something we take lightly. It's avoided if at all possible. The one case we do use Unsafe today we are considering removing in future releases in favor of a more targeted API.

[GabeSchaffer]

I think it's reasonable to say that adding another option to a union is like adding an optional parameter to a method. Even though the call site stays the same, making certain changes to the callee requires recompiling.

[Richiban]

Isn't this where the complement of type unions, type intersections, comes in?

((Cat or Dog) and Animal) pet = ...;

pet.Eat();

[johnazariah]

Are we going to be able to provide methods on the DU like all the other first class types in C#? Extension methods? How would this work for ad-hoc unions?

[mattwar]

You will of course be able to use extension methods.

The question we will have to decide on is whether the declaration syntax for a union allows you to specify methods or properties on the union type itself, or its member types. We stayed away from making a claim about that in this proposal, but it will definitely be discussed.

[Joe4evr]

The main reason I've been asking is because it'd be incredibly useful if Option (and probably Result too) can ship with an API that imitates covariance. The ideal usage would be something like this:

public class X { }
public class Y : X { }

public class Foo
{
    private Option<Y> GetY() => ....;

    // Imagine return type is restricted because of an interface or similar
    public Option<X> GetX() => GetY().ValueAs<X>(); // Method name TBD
}

But when writing an implementation in current C# there's a trade-off:

• As an instance method, a caller only has to specify the target type (👍), but the method can't be constrained (👎). This means there needs to be a decision on behavior when there is a value but it can't be converted to the target type.
• An extension method can be properly constrained so call-sites get verified that the conversion to the target type is valid (👍), but a caller would have to specify both types of the relation (👎) (absent partial inference).

[TahirAhmadov]

I would say the syntax should be changed slightly - instead of semicolons, commas should be used after each option member.

union struct U 
{
  A(int X, string Y), // also, record parameter naming rules should be adopted
  B(int Z),
  C, // this comma is optional
}

Then, we can add instance members as follows:

union struct U 
{
  A(int X, string Y) // for option, instance members can be added like records
  {
    public A(int x) : this(x, x.ToString()) { } // perhaps even ctors can be added?
    public void Foo() { }
  } // comma not needed anymore
  B(int Z),
  C; // semicolon denotes the end of options
  public void Bar() { }
}
U u = GetU();
u.Bar();
if(u is A a) a.Foo();

[Joe4evr]

  } // comma not needed anymore
  B(int Z),

I'd think a comma would still be mandatory there, but otherwise you've captured the spirit of what I meant when I said some additional language rules need to be thought up around case declarations. Specifically: It'd likely be necessary that all cases be declared in one "section" of the union type (i.e. no other kinds of members can be declared between case members). When using partial (be it for SG or organizational purposes) only one part can contain cases, similar to how partial structs can only have one part that can contain fields.

But the exact syntax is yet to be finalized anyway, so let's not get hung up too much on that.

[TahirAhmadov]

@Joe4evr also, similar syntax can be added to old school enums to add instance members (not sure how important it is with extensions, but still).
I kind of agree with you, comma would be OK to have even after the closing brace.

[johnazariah]

Defaults are fine if exhaustiveness is intrinsically guaranteed on the check right? Maybe I'm not understanding your statement correctly.

…

-J

On Thu, 25 July 2024, 15:54 Massimiliano Donini, ***@***.***> wrote: Will a default be forbidden in a switch on unions? It would be nice not to be allowed to opt out of exhaustivness checking with DU — Reply to this email directly, view it on GitHub <#8313 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGKWZ6I3ZTPQQBWOQMX5MTZOCHH3AVCNFSM6AAAAABLM3DJRGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJUGQ4TGOA> . You are receiving this because you commented.Message ID: ***@***.***>

[johnazariah]

May I suggest that this would make union types not first class in that sense...

…

On Thu, 25 July 2024, 14:02 Matt Warren, ***@***.***> wrote: That's yet to be determined. The current proposal does not allow for it. — Reply to this email directly, view it on GitHub <#8313 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGKWZY52ZTAPBOMK2V4Q7LZOB2DVAVCNFSM6AAAAABLM3DJRGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJUGQ2DEMQ> . You are receiving this because you commented.Message ID: ***@***.***>

[fabianoliver]

Fantastic proposal, unions would be a very welcome addition to the language!

I have slight concerns around the proposed Option<T> type.
The TL;DR is: I think it would be extremely useful it options for ref types are zero-cost, or at least as close to possible to this as possible.

Now, where does a type like this really shine?

If you're dealing with ref types, null is already a perfectly good "missing value" in almost all practical cases.
If you're dealing with value types, you're in a tougher spot as default(T) is often not a good marker for missing values. Fortunately, Nullable<T> does a brilliant job there.

Unfortunately, you're currently in trouble if you have an unconstrained generic parameter T. And that is troublesome in many ways:

1. T? DoSomething<T>() where ... - you won't know if T? is Nullable<T> or just T for value types unless you read and interpret the where constraints. It is rather easy to miss this or not even be aware of the fact that T? might not be Nullable<T> for value types - I've seen plenty of code that missed this fact. In my opinion, it's one of the few footguns C# currently has
2. Even worse, if T is unconstrained, you currently just don't have any great way to formulate optionality of any instance of this type using standard BCL types.

This is, in my opinion, the big primary use case where Option<T> would really come to the rescue. It would let you formulate optionality in a generic way that works and is consistent for both ref and value types.

Now, the slight issue with the current proposal: There's fairly measurable "unnecessary" overhead for ref types;

I've tried something very similar for one of my projects, effectively implementing Option similar to Nullable<T> without the type constraint (see the semi-related issue here ).
Which in turn, if I understand right, is likely quite similar to the proposed type here in terms of memory layout & general overhead.
In my case, the overhead introduced by the Option type benchmarked to be so significant that I had to abandon this approach again (and continue to be stuck in a bit of a limbo, as all alternative approaches come with significant downsides too).

In principle, if null is already a valid marker for a missing value for ref types, an Option<T> for T : class should, in an ideal world, be pretty much a no-op wrapper that comes without any memory overhead at all, and would "somehow" be optimizeable - whether by the JIT or however else - so that all type checks etc. would effectively just be a null check of the underlying value.

If that isn't feasible, I fear we might be facing one of two outcomes:
A) The Option type would be relegated to use cases where that overhead is definitely tolerable; meaning, it might only be usable sparingly in select places
B) The Option type does proliferate throughout the wider ecosystem (as I think it should) - but in turn introducing performance and memory overhead for a wide range of APIs

[Joe4evr]

If so, that particular optimisation might not be applicable to the case of Option<T> for reference-type Ts, just because no union component is a value type (even if the union type itself is a value type)

I see. Yes that's right, but Option<T> wouldn't be having that optimization in any world since only one of its cases has a field at all. The point there was that if you defined your own union that had a bunch of cases, it'd be a no-brainer to have the compiler collapse mututally exclusive fields of the same declared type (including of reference types) in the "parent".

The former should not be valid, so T should likely be constrained to notnull, i.e. Option<T> where T : notnull.

So you'd rather give the finger to those scenarios where null != non-existant just because you've never had to write code for those domains, than design the feature for the widest possible reach so that it can even benefit areas you don't personally care for? If you don't like Option<object?> you can write an analyzer for yourself to forbid it in your own codebases, but that's no reason to claim it couldn't ever be useful to anybody outside of your world.

[snarbies]

I'd support a distinction between a null value and no value. I find the distinction between undefined (unset/unknown/unspecified/invalid) and decidedly null to be useful in javascript as long as you take care to use those values in semantically correct ways.

[fabianoliver]

So you'd rather give the finger to those scenarios where null != non-existant just because you've never had to write code for those domains, than design the feature for the widest possible reach so that it can even benefit areas you don't personally care for?

Well, that's the thing - that's not a given.

The likely overhead of the current proposal would render it unusable for more performance sensitive scenarios such as my own, and surely others. So I don't agree with the notion that the proposed approach would have the widest reach - the current proposal would be making a choice that rules out a range of use cases (as pretty much any design decision does I reckon).

Will you gain more users that need support for null-but-not-missing types than you'd lose users who'd have to abstain because of performance considerations?
Even more so considering the former is already easily possible with custom wrappers, whereas .NET does not currently have any way to achieve the latter (very) efficiently at all?

I don't know, and if the language design team decides supporting null-but-not-missing types is more important (or achieving lower overhead isn't feasible anyway), that's completely fine. But it seems like a good point in time to think it through and make that deliberate decision.

[fabianoliver]

After giving it a bit more thought - the 2 things we discussed ("more efficient/possibly zero cost options for reftypes in particular" and "ability to distinguish between null and missing") might not even have to be mutually exclusive.

Say Option<T> worked as I described above - i.e. not allowing nulls / holding null values being the same as Option<T>.None.
We would presumably still be able to formulate "null or missing" by just using a union as the inner type itself, i.e. Option<(T or default)>.

That does assume that Option<T> is not the same as (T or default), so deviating from the proposal.

[dersia]

honestly when I think about DTOs and parsing json, there is a clear difference between a missing property and a property set to null and there are domains where this difference is important.

having said that I would love to have a SourceGenerator for Option<T>.

[AllMembersOptional]
public record MyDTOs
{
    [JsonPropertyName("myProperty")]
    public string? MyProperty { get; set; }

    [JsonPropertyName("myProperty2")]
    public string? MyProperty2 { get; set; }
}

that would than become:

public record MyDTOs
{
    [JsonPropertyName("myProperty")]
    public Option<string?> MyProperty { get; set; }

    [JsonPropertyName("myProperty2")]
    public Option<string?> MyProperty2 { get; set; }
}

[hamarb123]

I think the proposal is pretty great overall :) , but I do have a few concerns / suggestions

I think it would be great if we could specify an open union somehow, but still have all the benefits of the new union types (like the nice pattern matching syntax, and easy declaration, whilst still only allowing me to add new options later), for example, if I have one like this:

union MyMathOperator
{
    Add(int left, int right);
    Subtract(int left, int right);
    Multiply(int left, int right);
    Divide(int left, int right);
    Negate(int left);
}

But I want to leave open the possibility of adding more cases later (like Factorial maybe for example), and I expect my consumers to still get a warning to add some default handlers. I think it would be good if we could opt in to marking it as open somehow, even though it's a union. For these ones, it would not be considered a breaking change to add a new case, which it (presumably) would be for normal union types.

It would also be useful in some cases if we could specify the kind enum's type and/or values explicitly, for example:

union struct WasmShortInstruction : byte
{
    Unreachable = default; // or 0x00
    Ref_Null(RefType inlineType) = 0xD0;
    I32_Eq = 0x46;
    //...
}

The use of records concerns me a bit, as it doesn't seem like it would be possible to get a reference to the "fields" (is this what they're called for unions?). For example, it does not seem like it would be possible to write the following in any way (without completely abandoning all the benefits of unions):

union struct MyLargeUnionStruct
{
    Case1(InlineArray16<float> values);
    Case2(InlineArray16<int> values, int controlValue);
    Case3(InlineArray16<int> intValues, InlineArray16<float> floatValues);
    Case4;
    Case5(int value);
    //...
}

int Handle(in MyLargeUnionStruct x) => x switch
{
    Case1(ref readonly var values) => HandleCase1(in values),
    Case2(ref readonly var values, var controlValue) => HandleCase2(in values, controlValue),
    Case3(ref readonly var intValues, ref readonly var floatValues) => HandleCase3(in intValues, in floatValues),
    Case4 => HandleCase4(),
    Case5(var value) => HandleCase5(value),
    //...
};

I also think it would be good if we document [Closed] as having possible future runtime enforcement, which ensures that only types defined within the same assembly can inherit/implement it - this would allow additional optimisations even in a JIT environment where we currently cannot make the closed-world assumption. (If combined with my earlier suggestion, perhaps these would be better named [InternalInheritanceOnly] and [ClosedUnion]/[Union(Closed = true/false)] or something)

I also have some concerns about (A or B or C ...) always translating into object, as it feels a bit like a dynamic 2.0, where we later say "actually, don't use this because it's bad for performance", and the encoding boxes us in a corner in the future since we'd be unable to fix it if we think a runtime solution would be better at that point. Perhaps we could have some new types in the BCL like the existing ValueTuple structs, that for now just wrap an object, that we could then easily improve later via specialised runtime support if we felt it was beneficial. (it's probably a good encoding in cases where all of the types are not structs though)

Thanks for the detailed proposal document though :) I feel much more optimistic about this feature actually happening and will work well (performance-wise) now overall

[hamarb123]

I'm not sure I understand what is meant by "openness".

I defined what I meant by this in an earlier comment.

Regarding "enum kind", or what looks like backing values to me, I similarly can't understand the purpose. What does "byte" mean as opposed to not specifying it? What do the backing values mean? A usage example would be great.

If you specified byte for example, byte would be used for the kind enum instead of int.
e.g., you'd get:

struct U
{
    public enum UnionKind : byte { A = 1, B = 2, C = 3 };
}

instead of:

struct U
{
    public enum UnionKind /*implicitly int when unspecified*/ { A = 1, B = 2, C = 3 };
}

It is a breaking change to change the backing enum type, so if we consider adding new members to unions not to be a breaking change, then you'd want to be able to specify it.

Being able to specify the backing type and values is something Rust supports for example with its enums (which are the equivalent to these).

An example usage would be that ideally you would have Option<TValue> and Result<TValue, TError> only use 1 byte for the tag where useful (by which I mean, if I have Option<byte> for example, there's no reason to use an int tag and blow the whole thing up to 8 bytes always due to alignment, when it could just use 2), since they would only ever be 0/1 (/2 for Result), and would never be extended.

If you're able to add more members to a union without it being a breaking change, then byte could not be inferred ever, since if you went up to 257 members (including default if not explicitly specified), you'd suddenly need to use a ushort instead, which is a breaking change. Depending on whether we expect changing a union from open to closed to be a breaking change or not (without manually adding : int anyway), this could also spill over to closed unions too, where you definitely want to be able to only use a byte of memory for the tag if possible (which would be 99.9% of the time probably).

[TahirAhmadov]

I defined what I meant by this in an earlier #8313 (reply in thread).

I saw it and I'm still confused.

The difference between the closed/open ones I proposed (that I was attempting to explain properly anyway 😄) would be that open ones would warn if the _ case is not covered (as you're expected to actually add more at some point),

That sounds like a coding practice rule which you would like to have. As far as the proposal goes, it already auto-emits a default: by default (ha ha) which throws, and you can define your own default: if needed. I hate to be that guy but it sounds like you need to create an analyzer which requires an explicit default: case when a union type is decorated with an attribute. That is not an open union.

and for the closed ones, it would be a breaking change under the breaking changes rules to add another case ever.

It's a breaking change to add a new case (option) member to a union regardless of whether it's marked as open or closed. Rather, it depends on what kind of default: is emitted (the implicit, throwing one, or the explicit user-defined one), whether the calling code is going to pass a value of the newly added case type, how it deals with exceptions, etc. Also, there are numerous other potential breaking changes, say if state is added/modified/removed on an existing case, all these changes which can affect the layout of the struct. There is no safe-guarding against breaking changes by marking a union as "closed", be it a keyword or an attribute.

It is a breaking change to change the backing enum type, so if we consider adding new members to unions not to be a breaking change, then you'd want to be able to specify it.

This is the crux of the confusion here. With struct unions, it's always a potential breaking change to add a case, like I explained above, because of potential changes in struct size and layout. Trying to achieve backwards-compatibility in adding new cases scenario is fraught with peril and can only happen in some scenarios. As such, I don't think it should be a promise that the language provides at all - you change an struct union in any way, you need to account for those changes, period. Otherwise, we would need to define a very complicated set of rules under which adding cases is "safe" - I can easily imagine it being a big source of evil bugs.

WRT the tag integer value, the compiler should auto-decide what size to use - you're right, 99% of the time it will be a byte.

WRT specifying the tag values explicitly, if I understand correctly, the objective here is to make it possible to "safely" add a new case in some cases. However, since 1) it's such a complicated set of rules for when adding a case is safe, and 2) IMO it makes no sense to even try outlining these rules, and 3) it makes much more sense to just dictate that any struct union changes require a rebuild, then 4) there is very little value in specifying tag values explicitly. There is no proposed syntax to "cast" a union to an integer tag value (at least that I'm aware of); what number the tag field contains should be an implementation detail and opaque to the user.

Please let me know if I misunderstood anything.

[hamarb123]

I've answered most of your comment below - I've collapsed it so that it doesn't fill up this discussion even further. If you want to continue discussing this, I'm happy to, but I suggest we do it on the c# discord instead, so we don't spam everyone here (since we don't seem to be getting anywhere quickly 😁).

Response

It's a breaking change to add a new case (option) member to a union regardless of whether it's marked as open or closed.

You yourself said it wasn't a breaking change to do this:

My understanding is that if you want "other", you just add that as the final option:

union struct U 
{
  A(int X, string Y),
  B(int Z),
  C,
  Other(object Data)
}

Also, there are numerous other potential breaking changes, say if state is added/modified/removed on an existing case, all these changes which can affect the layout of the struct.

Just because one thing is a breaking change, doesn't mean that everything is. And struct layout change (due to adding a new case) would not really be a breaking change here, since you cannot directly observe it without unsafe code or reflection (which generally need to be explicitly documented to count as something you can rely on). If we considered everything that potentially changed things to unsafe code or reflection in any way, we would almost never be able to change or add any API. Other than the tag size potentially changing, there is no reason that adding a new case to a union is a breaking change (other than people getting a warning that not all cases are covered), unless you're relying on things that are most likely UB.

With struct unions, it's always a potential breaking change to add a case, like I explained above, because of potential changes in struct size and layout.

In addition to what I said above, if you have any managed fields, the runtime can already do this for you (and has in the past iirc).

WRT specifying the tag values explicitly, if I understand correctly, the objective here is to make it possible to "safely" add a new case in some cases.

This is not the only use of this, worst case you could just put them in the same order forever. Other uses include actually using the integral value of the tag for something, without having to map it every time.

There is no proposed syntax to "cast" a union to an integer tag value (at least that I'm aware of); what number the tag field contains should be an implementation detail and opaque to the user.

The Kind property is public, I assume you are able to just call it like any other public API, I could be wrong. But I think it would be a shame if you could not get the integral value out of it. I have many uses for this.

WRT specifying the tag values explicitly, if I understand correctly, the objective here is to make it possible to "safely" add a new case in some cases. However, since 1) it's such a complicated set of rules for when adding a case is safe, and 2) IMO it makes no sense to even try outlining these rules, and 3) it makes much more sense to just dictate that any struct union changes require a rebuild, then 4) there is very little value in specifying tag values explicitly

1 - The rules are not that complicated: don't add or remove or change type of fields to any case, don't rename any case, don't change the tag value for any case, if it's unmanaged don't make it managed (if relevant). This follows rules of other similar things: e.g., enum values, and field and constructor breaking change rules.
3 - I tried to have this argument online with someone in the c# discord about the default exception case - the conclusion basically is that this doesn't happen in many cases and we do actually have to cater for this at least to the extent where we don't introduce bugs in things where possible.
4 - Just because it is not valuable to you, doesn't mean it isn't valuable to other people. Multiple examples where this could be useful have already been provided. For example, my WasmShortInstruction union example, along with the versioning scenario from @mattwar (one of the people working on this feature).

That sounds like a coding practice rule which you would like to have. As far as the proposal goes, it already auto-emits a default: by default (ha ha) which throws, and you can define your own default: if needed. I hate to be that guy but it sounds like you need to create an analyzer which requires an explicit default: case when a union type is decorated with an attribute. That is not an open union.

The point is to warn the user that there will be new cases added to the enum in the future, and that they may want to handle the default case - just like with any other switch pattern/expression where you don't handle all the possible cases. I'm not writing an analyser for something that is the end-user's problem, but I would add an attribute to indicate that "actually, this is not expected to never change". Just like how nullable annotations indicate that something might be null or cannot take null, and I was never going to write an analyser to indicate that but I am happy to add the well-supported annotations to achieve this.

That is not an open union.

I don't really see how you can say that considering you claim to not know what I mean by it. I'm saying an open union is a union which you can add new cases to without any breaking changes, and that you're expected to actually add new cases to at some point, which is something that would already 80% work without explicit support anyway (with the only real thorns being no warning on not covering _, and potential issue with underlying enum tag type if you ever add more than 256 cases depending on how its implemented). I'm saying this is what I mean by open union, because I don't know if there's an actual term for it or not - in rust they are called #[non_exhuastive], but just like with almost anything in programming, there are probably a lot of terms that all mean the same thing, and each of which also have many other meanings. I don't really care what it's called and am happy to use the correct terminology if I'm told what it is I'm referring to.

and for the closed ones, it would be a breaking change under the breaking changes rules to add another case ever.

It's a breaking change to add a new case (option) member to a union regardless of whether it's marked as open or closed.

It's only a breaking change if we make it a breaking change. As I explained earlier, you can very easily implement them in a way that allows adding new cases to unions without any real issues other than the consumer not being told they haven't covered _ and the tag enum size thing. Nothing else necessitates adding a new case to a union being a breaking change (other than the usual stuff, like unmanaged -> not unmanaged, adding new public fields which in turn also changes the constructor in this case, etc.).

[TahirAhmadov]

You yourself said it wasn't a breaking change to do this: .....

But that's not "adding new cases"; you ship your union with the Other case from the get go, and the users know they need to handle the Other.

And struct layout change (due to adding a new case) would not really be a breaking change here, since you cannot directly observe it without unsafe code or reflection (which generally need to be explicitly documented to count as something you can rely on).

It will be, though.

1. If the code using a union is re-compiled after a new case member is added, you can (you will have to) add code to handle that new case member.
2. If the code is not re-compiled and the DLL with the union is replaced and its size/layout is now different, all bets are off. I would expect this to be undefined behavior, but I'm not sure.

Regarding "open" vs "closed", usually the conversation is around the existing enum types being "open" - you can take any integer value and cast it to any enum type. This cannot be done with type unions by definition; 1, the state is not defined for an unknown "tag" value, and 2, for class unions, it relies on instance anyway, so you can't even physically do it. I don't want to sound pedantic but I think terms are important and it's best if we all keep using terms as understood by as many people as possible.
Your definition of "open" vs "closed" is completely different; it basically implies that the author "promises" that a union will never get new case members. I see a few issues with this. 1, proposal already addresses it with both implicit and explicit default: labels. 2, like I said an analyzer can be created which 2, I don't think C# (or any other language, for that matter) has ever had any constructs, which stipulate that any given piece of code "will never change". Anything can be changed, say, a new team starts working, and has a different opinion on the subject, etc. Even if a type union was marked as "closed" (in your understanding of that word) originally, it doesn't really mean anything.

[snarbies]

It will be, though.

1. If the code using a union is re-compiled after a new case member is added, you can (you will have to) add code to handle that new case member.
2. If the code is not re-compiled and the DLL with the union is replaced and its size/layout is now different, all bets are off. I would expect this to be undefined behavior, but I'm not sure.

On 1, not if you have a default, which would be required for an open union anyways. On 2, I'm not sure what you're saying here. What bets are off? Only code that depends on the unmanaged layout would be affected, which the author does not necessarily guarantee.

the state is not defined for an unknown "tag" value

That would be handled by the default tag. It's already a given that the state is an enigma.

for class unions, it relies on instance anyway, so you can't even physically do it

?

[Richiban]

I don't see anything in the proposal about co- and contra-variance being added to classes and structs. While it's not required for unions (and certainly not for v1), I think it's going to seriously hurt the adoption of types such as Option<T> when users discover that Option<string> is not assignable to Option<object>, for example.

[Joe4evr]

The main reason I've posted about defining regular members (methods/properties/etc.) in unions is as a lead-up for Option and Result to ship with an API that imitates covariance for exactly those kinds of scenarios.

[xoofx]

Just want to say: Thank you for putting the proposal together, I love it, looking forward to it! 🚀

[qrli]

To add a use case: serialization.

Many serialization formats support some kind of union type. E.g. Json, protobuf, msgpack, Bson in MongoDb. To serialize/deserialize unions in them, the typical solution in C# is to declare a base class with derived classes. A key gap is that deserializers need to know all the possible derived types, which must be specified again somehow, e.g. by annotating with attributes. This is similar to the exhaustiveness requirement. A built-in union type will definitely simply this.

In case a union includes a primitive type option, the class heritance solution cannot be used. Well, we can still hack it by implementing custom serializer/deserializer. But that's a bit stretch for such a simple task. The ad hoc union in this proposal looks like a good fit for this scenario.

[mattwar]

Serialization is an important scenario. You may have missed it in the proposal.

[paphillips]

I'll also add to the use cases. The lack of C# unions is an impedance mismatch for code generation against popular API specifications, for example:

1. OAS 3.0 (swagger): oneOf as related to Json Schema oneOf
2. TypeSpec Union
3. GraphQL Union Types
4. XML Schema Union datatype
5. Raml Union Type

C# type unions could also help with the tendency of some json-based apis (and RDF if memory serves) in the wild to treat arrays and singles as interchangeable.

I'm really looking forward to seeing C# on this page!

Hopefully the Entity Framework folks will be in the loop as things evolve.

[TahirAhmadov]

What about "common" data?

union struct U(DateTime P)
{
  A(DateTime P, int X, string Y) : base(P), // do we explicitly specify these parameters?
  B(int Z), // or do we implicitly bring them "forward" to all options?
  C,
  D(_, TimeSpan Q) // or maybe some syntax to make it more readable that base parameters are "forwarded"?
}
U u = new A(DateTime.Now, 123, "abc");
Console.Write(u.P);
u = new B(DateTime.Now, 456);

[HaloFour]

I think the choice is obvious...

Yeah, the latter.

I think we're discussing a common property that is to be evaluated based on the other data elements from each case, not one that is itself a data element:

union struct U 
{
  A(int X, string Y),
  B(int Z),
  C;

  public DateTime P => this switch {
    A a => a.P,
    B b => b.P, 
    C c => c.P
  }
}

[TahirAhmadov]

I think we're discussing a common property that is to be evaluated based on the other data elements from each case, not one that is itself a data element: ...

That may be what you and maybe others are discussing, but that's definitely not what I proposed in my top level comment which started this branch of discussion. I'd like to see specifically shared state which is available for all union cases.

[TahirAhmadov]

For the record, I do think instance (and static) members should be allowed both at the "base" and "option" levels, making the scenario you're talking about possible.
But again, that's something different from what I'm looking for.
Behind the scenes, my common state feature can be implemented using this base level instance property which is emitted by the compiler, if that's a cheaper way to go about this. Basically, you write the union in the manner which I proposed, and it gets transpired into the manner which I said I don't like (with all the boilerplate).

[HaloFour]

In that case I wouldn't expect the syntax to be in any way different to how you would declare the same with primary constructors deriving from a type with a required constructor:

// today with records:
public abstract record U(DateTime P);

public sealed record A(DateTime P, int X, string Y) : U(P);
public sealed record B(DateTime P, int Z) : U(P);
public sealed record C(DateTime P) : U(P);

// tomorrow with DUs, with syntax spaghetti
union struct U(DateTime P)
{
  A(DateTime P, int X, string Y) : U(P),
  B(DateTime P, int Z) : U(P),
  C(DateTime P) : U(P)
}

I fully expect that the cases can reorder the data elements as it sees fit, or omit it entirely as long as it can pass a value to the underlying "constructor":

union struct Color(byte R, byte G, byte B) {
    Red : Color(255, 0, 0),
    Green: Color(0, 255, 0),
    Blue :  Color(0, 0, 255),
    Other(byte R, byte G, byte B) : Color(R, G, B)
}

[TahirAhmadov]

@HaloFour while that does create some boilerplate in some scenarios, I can live with that because of the benefits of consistency and versatility. I especially like your Color example.

[TahirAhmadov]

For ad-hoc (anonymous) type unions, was any consideration given to optimizing them for struct-only options to avoid boxing, or it's too complicated?

(int or DateTime) x = 123;
// compiled to something like this:
struct IntOrDateTime
{
  int _tag;
  [FieldOffset(4)]
  public int Int;
  [FieldOffset(4)]
  public DateTime DateTime;
}

PS. I thought about this more. For non generic types, it's doable (I think) - there are complications, but nothing insurmountable. The question is, what to do with generics if they're where: struct? With my admittedly limited experience in this space, I kind of think it's doable, but I have a feeling there are problems I haven't imagined.

[colejohnson66]

Theoretically, any managed/reference type could be packed into a singular object at offset 0 and, any unmanged type unioned at offset 8 (even on 32-bit for simplicity):

[StructLayout(LayoutKind.Explicit)]
public struct OnlyNonReferences
{
    [FieldOffset(0)]
    private A _a;
    [FieldOffset(0)]
    private B _b;
    [FieldOffset(0)]
    private C _c;
}

[StructLayout(LayoutKind.Explicit)]
public struct ContainsReferencesAndNonReferences
{
    [FieldOffset(0)]
    private object? _reference;
    // four bytes of padding on 32-bit systems
    [FieldOffset(8)]
    private A _a;
    [FieldOffset(8)]
    private B _b;
    [FieldOffset(8)]
    private C _c;
}

Things get complicated if a struct contains references (i.e., struct, but not unmanaged). You'd have two options:

1. Box it into _object — Simple solution with boxing overhead (could possibly remove unboxing overhead with Unsafe.Unbox, but you're still boxing each write)
2. Give it a dedicated field and offset the other unmanaged ones by that — Complicated to compute; What would FieldOffset be for B and C if A contained references

Basically, unless the runtime/GC is augmented to recognize unions (which I would love, but doubt it would happen), the simple solution is to just give each element its own field, like OneOf does.

[mattwar]

We did spend a few months trying to solve anonymous ad-hoc unions with the same implementation solutions as union structs, and even with a middle-ground variant struct that only kept primitives from being boxed. We proved it could be done, but had the drawbacks of the limitations that struct solutions bring and would impact interchangeability.

[HaloFour]

@mattwar

Did that include a family of ValueUnion<...> types that would have special runtime support like Nullable<T>?

Just throwing spaghetti at the wall here:

ValueUnion<int, string> union1 = 1234;
object boxed = union1; // runtime boxes the underlying int
if (boxed is int) { ... } // type check passes
ValueUnion<DateTime, int> union2 = (ValueUnion<DateTime, int>) boxed;  // runtime supports unboxing into another union

I'm sure it's infinitely more complicated and has a billion edge cases.

[mattwar]

@mattwar

Did that include a family of ValueUnion<...> types that would have special runtime support like Nullable<T>?

Just throwing spaghetti at the wall here:

ValueUnion<int, string> union1 = 1234;
object boxed = union1; // runtime boxes the underlying int
if (boxed is int) { ... } // type check passes
ValueUnion<DateTime, int> union2 = (ValueUnion<DateTime, int>) boxed;  // runtime supports unboxing into another union

I'm sure it's infinitely more complicated and has a billion edge cases.

We did model a family of generic struct types like you mention, but none with magic runtime boxing support. Yet, even with that, other issues like making ValueUnion<int, string> be interchangeable with ValueUnion<string, int> would make it less preferable.

[HaloFour]

Agreed, transitivity would get dicey real fast. I would imagine that flattening could too, given that with generics something like ValueUnion<int, ValueUnion<int, string>, ValueUnion<string, int>> could be possible.

I think a lot of these issues arise mostly because of the expectation to use adhoc type unions in signatures and generics. Not permitting this and treating them like anonymous types I think affords the compiler a lot more flexibility in how it encodes and interacts with said unions. My concern is that adhoc type unions end up being used in place of overloads and generics because they will seem easier, despite the performance penalty of doing so. It's already been mentioned that arithmetic operators could work over a union of numeric types.

[johnazariah]

Can I make a suggestion to keep these type proposals mathematically sound?

A Tuple type is basically a "product" type, and we can currently arbitrarily construct ad-hoc products using it.
A Union type would be the analogous "sum" type, and we would be able to arbitrarily construct ad-hoc sums using it - without really any need for a custom syntax for ad-hoc unions. Unions could be made to be pattern matched without need for a default if all options in the union have been matched.

Records are basically named tuples with a syntax to create product types with named members.
If we had a way to specify named unions to create sum types with named options, I would suggest this would be the MVP for the feature.

Adding methods to a named union type could be done analogously to how they are done with records.

The more I think about it, a special syntax for ad-hoc unions leaves the language non-orthogonal from a mathematical point of view, because there is no special syntax for ad-hoc tuples (say with and in the syntax).

[mattwar]

I'm maybe misunderstanding your last point, but the tuple syntax is already an ad hoc syntax for tuples.

[johnazariah]

That is my point. We have Tuple<T1, T2..> for ad-hoc product types. Can't we just have Union<T1, T2..> for ad-hoc sum types, and eschew the (T1 or T2) custom syntax because there isn't an analogous (T1 and T2) equivalent for products.

Also, named products are basically record with the current record syntax. I'm suggesting that it is sufficient to have the same form but with union as a keyword instead.

This would basically allow method extensions for named unions just like there are method extensions for records, and all the co- and contra- variant affordances for generic types could also apply consistently across.

From a type-theoretic perspective, record and union are complementary in function but analogous in structure...

[KennethHoff]

That is my point. We have Tuple<T1, T2..> for ad-hoc product types. Can't we just have Union<T1, T2..> for ad-hoc sum types, and eschew the (T1 or T2) custom syntax because there isn't an analogous (T1 and T2) equivalent for products.

Are you unaware of the ValueTuple syntax, or is there something else you're referring to here? Because of not, there very much is an analogous equivalent for product types.

Granted, it doesn't use the and keyword but other than that it seems identical to what you're proposing

[johnazariah]

You are so absolutely right! I have no idea why that didn't register with me!

Thank you for clarifying, please disregard my comment about the (T1 and T2) syntax!

OK I now see what the (T1 or T2) is analogous of and I don't have a problem with it...

[erik-kallen]

Excellent proposal, but:

1. Is the Option type really a good idea? Sure, if we could go back in time and remove nullability it would have been the way. But where we are now, it will introduce a second way of doing the same thing as we already can with null. Will the BCL be amended so all methods that accept a parameter that can be null also have an Option overload, or will it forever be a second-class citizen? Seems to me that adding this will cause pain when using third-party libs written by people who wish they worked with Rust. If people really need to write Option (and potentially have stronger null enforcement), could that not be done as syntactic sugar in the compiler instead?

2. What are the plans for the Result type? It does have some of the same issues as the Option type, but probably less. Will there be new BCL methods (eg. Result<Stream, SomeType> File.OpenReadResult())? Can the type somehow integrate with the exception system? For example, could a warning be issued if a Result-returning method throws somehow? Or perhaps catch and convert exceptions based on some pattern (for example if there is an implicit conversion from an exception type to a Result types error type)?

[Joe4evr]

1. Is the Option type really a good idea? [...] But where we are now, it will introduce a second way of doing the same thing as we already can with null.

It's not only about null. As I stated in another reply:

There are still domains where there is a semantic difference between "this value is null" and "there is no spoon value to begin with". That semantic can't be modeled in the CLR with only null, so there's definitely a need for something to deal with that kind of scenario.

[erik-kallen]

Sure, but do those domains need a BCL type? Many domains don't have BCL types.

[KennethHoff]

Sure, but do those domains need a BCL type? Many domains don't have BCL types.

If we are getting unions, I think adding the most common ones into the BCL makes a lot of sense, which are "A or B" and "A or invalid".

[erik-kallen]

Many suggestions get dismissed by the team because they just add another way of doing something that is already possible.

TypeScript has come to the conclusion that adding utility types to the standard lib is often not a good idea because people often want slightly different behavior.

[crazycrank]

Has it been considered to implement ad hoc unions with compiler generated classes (similar to display classes and other existing approaches) instead of using type erasure? What's the reasoning to go the erasure route here?

It feels like this could limit potential use cases with reflection or generics in the future?

[colejohnson66]

Custom classes can cause a binary compat issue if the compiler doesn’t output the exact same types each time. For a simple example, consider changing OneOf<A,B> to OneOf<A,B,C>. Now, you’d need a dumb overload where OneOf<A,B> just forwards to OneOf<A,B,C>, but the compiler wouldn’t know to generate these overloads. And those overloads would have overhead with unpacking and repacking.

Basically, type erasure is the simplest way to implement this feature. Perhaps the LDM could revisit it in the future, but unions have been requested for so long, they probably want to get something good out that can be optimized later.

[mattwar]

Erasures gives us near perfect interchangeability, which is important in scenarios where the union types are not given a name and yet must be considered the same type at runtime.

A compiler generated class is a nominal type. Any two types with different names are different types at runtime, even if they contain the same members. In order to have them unify, the compiler needs to have perfect knowledge of all the possible uses statically. This falls apart when the unions are specified with type parameters that are unknown at compile time, leading to different union types being generated. Also, a compiler generated type must be generated somewhere, in some module. Two independent modules referring to the same ad hoc union would have two different generated union types, that would not be considered the same by the runtime and would lead to interchangeability problems for a third module that consumes both.

[cremor]

@mattwar This all makes sense from the compiler's point of view. But wouldn't it be possible to add union support to the runtime?

As a comparison: I heard that C#/.NET did generic types "the right way" while Java only represents them as object during runtime.
Isn't this a similar case now with unions? So wouldn't unions also profit from proper runtime support?

[mattwar]

@mattwar This all makes sense from the compiler's point of view. But wouldn't it be possible to add union support to the runtime?

As a comparison: I heard that C#/.NET did generic types "the right way" while Java only represents them as object during runtime. Isn't this a similar case now with unions? So wouldn't unions also profit from proper runtime support?

Yes, it would be possible, but not practical.

[crazycrank]

Just out of curiosity, could you elaborate on what makes it unpractical?

[chtenb]

Would it be possible to move the addition of an Option and/or Result type into a separate proposal and discussion? I feel this has nothing to do with the sum type syntax for two reasons

1. If it is decided that there will be no Result type added to the stdlib at this time, this has no impact on the remainder of the proposal
2. If this proposal gets rejected, Result types can still be added to the language. In fact, many people already have Result types in their own project utilities, including monadic operators etc for handling errors and chaining operations. The sum type syntax is not necessary for this, a closed type hierarchy does the job.

[amal-stack]

Is there a reason why ad-hoc unions use a verbose syntax with parentheses:

(A or B)

instead of something like:

A | B

or

A + B

?

I can see this getting longer in cases like:

((TextData or BinaryData) first, (Document or Database or Filesystem) second, (Person or Animal) third) 
Combine(IEnumerable<((TextData or BinaryData), (Document or Database or Filesystem), (Person or Animal))> elements) {
}

Instead of something like:

(TextData + BinaryData first, Document + Database + Filesystem second, Person + Animal third) 
Combine(IEnumerable<(TextData + BinaryData, Document + Database + Filesystem, Person + Animal)> elements) {
}

[KennethHoff]

I think what David is talking about (and I might be wrong) is that they're not sum types; You can either access (IList<T> or ISet<T>) myThing = ... as IList<T> or as ISet<T>. You cannot access myThing as if it was both of those things at once.

[R2D221]

I mean, yeah. You can't call, say, myThing.SetEquals(otherThing) because myThing could contain an IList<T> and not an ISet<T>. But it's important that unions are not exclusive. If they were, an assignment like (IList<T> ^ ISet<T>) collection = new OrderedSet<T>(); would have to fail because since typeof(IList<T>).IsAssignableFrom(typeof(OrderedSet<T>)) ^ typeof(ISet<T>).IsAssignableFrom(typeof(OrderedSet<T>)) is false.

[CyrusNajmabadi]

You cannot access myThing as if it was both of those things at once.

It's way too early to make that claim.

[vladd]

@DavidArno
It’s actually not exclusive. E. g.:

void Accept<T, U>(object x)
{
     if (x is (T or U) tu)
        …

Here T and U can be the same type, right?

[DavidArno]

@vladd, yes there are some curious side-effects to that exclusivity created by derived types. This is one of the reasons why it's so important that any union solution supports annotating the cases of a union with discriminators, as that then ensures true exclusive-or behaviour.

[zms9110750]

What is his memory layout like? If I create (TimeOnly or long), will I use hours and minutes as long?
Can I call a shared method? For example, (int or byte or long) i=1; i++
Can declared union types be closed and serve as a recommended specification for finite derived types? For example XML.Linq.
Can I union value types and reference types?(char or string).

[HaloFour]

Per this proposal, an adhoc union is nothing more than the value upcast to object. For value types that does mean boxing. The proposal doesn't go beyond treating them as anything different from object, either. So to invoke any member you would first have to match against the type, even if they would have a common signature.

[zms9110750]

If (A or B) cannot call a method, what about (IA and IB)?

[JoepGeevers]

I'm super excited about this, as I'm using OneOf<T0, T1, T2, ...> a lot.

One of the biggest problems that I have with OneOf now, is mixing async with non-async operations, and I wonder if union types will actually handle this.

So what I'm looking for is:

return await this.UserRepository.Read(userId) switch
{
    async User user => await this.AccountService.Deactivate(user.AccountId),
    NotFound notfound => notfound
}

Is this flow something I could expect? Or can I keep dreaming? 🌨️

[WashingtonARamos]

I'm on the same boat, using OneOf for the time being. What I did was create a method that receives an async function instead and returns the expected type, like so:

public class Result<T> : OneOfBase<T, Error>
{
    protected Result(OneOf<T, Error> input) : base(input) { }

    public static implicit operator Result<T>(T s) => new(s);
    
    public async Task<TReturn> MatchAsync<TReturn>(Func<T, Task<TReturn>> f0, Func<Error, TReturn> f1)
    {
        if (IsT0 && f0 != null)
        {
            return await f0(AsT0);
        }
        if (!IsT1 || f1 == null)
            throw new InvalidOperationException();
        return f1(AsT1);
    }
}

Then I can use use like this:

public void DoStuff()
{
    Result<string> someResult = "Some string";

    someResult.MatchAsync(
        async ok => await Task.FromResult(200),
        _ => 42
    );
}

[JoepGeevers]

That looks promising! It'll take me a bit to wrap my head around, but I'm going to play with it

[Enderlook]

Is it necessary for unions to implement record feature?
It would be nicer if you could opt-in to the record feature, so the compiler doesn't add a feature I may not be interested in.
This opt-in to record feature could be per case or type, i.e:

union struct U
{
    A(int x, string y);
    B(int z);
    C = default;
}

union record struct U
{
    A(int x, string y);
    B(int z);
    C = default;
}

union struct U
{
    record A(int x, string y);
    B(int z);
    C = default;
}

Of course, currently using record in ref-struct unions or ref-variants won't be allowed, as ref-structs don't support it.

[Richiban]

If they don't behave as records, they won't be particularly useful as you'll have to write all the properties and deconstructors yourself. For example, the union

union U
{
    A(string data),
    B
}

might be roughly equivalent to:

[Closed]
abstract class U
{}

class A : U
{
    public A(string data) {}
}

class B : U
{
    public B() {}
}

As you can see, the case class A is useless as it doesn't have any properties. You can't even deconstruct it.

[Enderlook]

Another thing (I post a separate comment because it's a different thing).
The following expression

u switch {
    A a => a.x,
    B b => b.z,
    C c => 0
}

Is translated to

u.Kind switch {
   U.UnionKind.A when u.TryGetA(out var a) => a.x,
   U.UnionKind.B when u.TryGetB(out var b) => b.z,
   U.UnionKind.C when u.TryGetC(out var c) => 0,
   _ => throw ...;
}

But it's checking the union kind twice (once in the switch, the other inside the TryGet[...] method), increasing its costs. ¿Wouldn't be better something like this?

if (u.TryGetA(out var a))
    return a.x;
else if (u.TryGetB(out var b))
    return b.z;
else if (u.TryGetC(out var c))
    return 0;
else
    throw ...;

If this method doesn't allow the usage of jump tables, then it could be instead:

u.Get(out var a, out var b, out var c) switch {
    U.UnionKind.A => a.x,
    U.UnionKind.B => a.z,
    U.UnionKind.C => 0,
    _ => throw ...,
}

That is, the compiler creates a method which has an out parameter for each variant of the type. When Get is called, it assigns the value to the correct parameter and returns the proper enum. To avoid unnecessary assignment cost, other variables are not set to default but skipped (Unsafe.SkipInit), this unsafety shouldn't be much concern as the method is expected to be called by the compiler.

[HaloFour]

As with pattern matching elsewhere I would expect that the exact implementation of the lowering would be kept implementation dependent so that the compiler could be free to emit whatever is felt to be the most optimized. For example, adding in a few case guards or combinatorial patterns and I would expect the compiler to rework the code completely to avoid having to evaluating anything more than once.

[Enderlook]

As with pattern matching elsewhere I would expect that the exact implementation of the lowering would be kept implementation dependent so that the compiler could be free to emit whatever is felt to be the most optimized. For example, adding in a few case guards or combinatorial patterns and I would expect the compiler to rework the code completely to avoid having to evaluating anything more than once.

That would be great, but AFAIK you can implement custom union structs, so its API can't be an implementation detail unless the compiler had 2, one for custom unions (defined) and another for the official unions (implementation detail). Which I guess would also be good.

[CyrusNajmabadi]

u.Get(out var a, out var b, out var c)

This would be N arbitrary sized writes. That seems undesirable. The switch and get-one approach seems the best. But we'll be measuring everything to find out for sure.

[hez2010]

Link #8428 so that it can be included in future LDMs.

TL;DR: it proposed a way to address type testing against boxed struct unions without harming performance in ordinary cases, with together a marker interface that can also be used to bring the language support to existing libraries like OneOf.

cc @CyrusNajmabadi @333fred

[zms9110750]

I have come up with a situation, I don't know if you have considered it or not

Foo<T>(this T t) where T : IA , IB

IA a=new A();
if( a is IB b)
{
  b.Foo()
}

[hez2010]

It's #6308

[TahirAhmadov]

#5263

[Kuurama]

Result being a struct type, #1239 Could allow for Aliasing Result<T,E> as a shorthand for domain/namespace specific Result types:
using Result<T> = Result<T,MyNameSpace.MyError>;
(I would even say global using would fit better in this example)

It would feel like Rust with this syntax:
type Result<T> = std::result::Result<T, MyError>;

I'm just stating this because this proposal being available at the same time Union arrives would reduce the boilerplate around methods. And it could make the feature more appealing because if shipped with proper examples to a new Error Handling mechanism (Error as value), people wouldn't fear the bigger return type names.

public Result<MyType,ValidationError> Validate(MyTypeDto myTypeDto);
To ->public Result<MyType> Validate(MyTypeDto myTypeDto);
Or -> public ValidationResult<MyType> Validate(MyTypeDto myTypeDto);

I can also highlight it better with a more abusive example representing some database Io error but with a concrete optional type rather than a nullable returned type:
public Result<Option<MyType>, DataBaseError> GetMyTypeFromId(MyType.Id id);
To -> public Result<Option<MyType>,DataBaseError> GetMyTypeFromId(MyType.Id id);

One way to make this even shorter could be with using OptionalResult<T> = Result<Option<T>,DataBaseError>;
Which makes -> public OptionalResult<T> GetMyTypeFromId(MyType.Id id);
But then that would be up to the programmer to design a proper internal abstraction.

That way, we can define our 'own types' to essentially be alias on already existing structures with all their own set of extensions. And essentially enjoy more the BCL types and their features (when it's about structures in this case)

[Daeer-Projects]

Excellent proposal. I'm looking forward to using Type Unions in C#.

My question is specifically about the common unions. How will we handle multiple variables set from some service?

Take this scenario, for example. We have three services that return things. Now, we need to execute a method that uses all three of those variables.

What is the proposal to check that all three variables are of type Some?

I do not like these ideas.

Option<int> variableOne = serviceOne.GetOne();
Option<int> variableTwo = serviceTwo.GetTwo();
Option<int> variableThree = serviceThree.GetThree();
int total = 0;

if (variableOne is Some)
{
    if (variableTwo is Some)
    {
        if (variableThree is Some)
        {
            total = SumValues(variableOne, variableTwo, variableThree)
        }
    }
}

return;

int SumValues(int a, int b, int c)
{
    return a + b + c;
}

Or this:

Option<int> variableOne = serviceOne.GetOne();
Option<int> variableTwo = serviceTwo.GetTwo();
Option<int> variableThree = serviceThree.GetThree();

int total = variableOne switch
{
    Some: value => 
    {
        variableTwo switch
        {
            Some: valueTwo =>
            {
                variableThree switch
                {
                    Some: valueThree => 
                    {
                        return SumValues(valueOne, valueTwo, valueThree);
                    },
                    None: => 0;
                }
            },
            None: => 0
        }
    },
    None: => 0
};


return;

int SumValues(int a, int b, int c)
{
    return a + b + c;
}

I'm curious about how this is going to look. Has any thought gone into how we will consume the Option<TValue>?

[CyrusNajmabadi]

Expected approach would be like:

int total = (o1,o2,o3) switch
{
  (Some(var v1), Some(var v2), Some(var v3)) => v1+v2+v3,
  _ => 0,
};

[HaloFour]

I'm curious about how this is going to look.

Nevermind, Cyrus beat me to it. :)

The question would be how pattern matching on a DU would look like, as how they are typically built now has some friction around nested types and generic inference. Tagged unions as structs would require all new language support, but hopefully they still look and feel very similar to type patterns. From there the ability to match multiple values by using a tuple should apply per normal, and the compiler is smart enough to elide the tuple.

Also, as an if statement:

if ((o1, o2, o3) is (Some(var a), Some(var b), Some(var c))) {
    Console.WriteLine(a + b + c);
}

[orthoxerox]

For math operators in particular, I wouldn't mind if most operations were auto-lifted like they are on Nullable<T>: (o1 + o2 + o3) ?? 0.

Alternatively, I would be fine with coalescing each one: o1??0 + o2??0 + o3??0.

Finally, a Rust-style "bail" operator, while not matching your specific requirement, would simplify a lot of newly written code: o1? + o2 + o3?.

[alsi-lawr]

The way that LanguageExt has approached this is by making Option linq-compatible, so you can do:

from val1 in MyOption1
from val2 in MyOption2
select val1 + val2;

which would be equivalent to:

MyOption1.Map(val1 => MyOption2.Bind(val2 => val1 + val2));

I think taking inspiration from LanguageExt would be the best approach here, because it's been developed for a very long time and has been proven to be very useful.

[zms9110750]

Whether to use inclusion or inheritance to extend enumerations has always been a question.
But can we use this method to combine multiple enumerations together for direct use?

One question is, how does generic constraint handle union types? If a state machine requires an enumeration as an identifier, can we use a union enumeration to handle it?

[asontu]

Reading the current proposal I have two questions that I don't see in the current FAQ or discussions.

Negative pattern matching

Since writing foo is not Cat or Dog or Bird translates to foo is not Cat || foo is Dog || foo is Bird which isn't want I want, I've gotten in the habit of using braces and writing foo is not (Cat or Dog or Bird) to get the desired result. This looks very similar to the proposed if (u is (Dog or Cat)) example mentioned that would result in a "type test with ad hoc union".

Would this clash? Would it cause boxing overhead not associated with the current pattern matching if I upgrade and don't change my code?

Inference and implicit operator

Under Inference it says

Ad hoc unions can be inferred from context when that inference would not otherwise have been possible.

Does this include a found implicit operator? So in the example:

Dog rufus = ...;
Cat petunia = ...;
Bird polly = ...;

// u : (Dog or Cat or Bird)
var u = 
      x == 1 ? rufus
    : x == 2 ? petunia
    : polly;

If both Dog and Cat had an implicit operator to convert them to type Bird, would the compiler pick that and var u would always be of type Bird? Or would it only find a common base type like Pet?

[ScottKane]

I added a suggestion to: #9410 (comment)

But I think it probably makes more sense here so I will repost:

This is technically already possible in C# so adding unions should just be some lowering sugar to make working with it nice.

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

[hez2010]

This is technically already possible in C# so adding unions should just be some lowering sugar to make working with it nice.

This is not possible without additional runtime support, otherwise you will encounter consistency and correctness issues. Consider:

Is<Test>(new A());

bool Is<T>(object obj) => obj is T; // the compiler doesn't know anything about Test here so the code would return false instead of true.

[ScottKane]

Oh nice, but the syntax is possible, it will just take additional handling for the cases where any of the types included are reference types. Falling back to something this seems reasonable:

public struct Test : ISummable
{
    private readonly TagType _tag;
    private readonly object _value;
   
    public bool IsA => _tag == TagType.A;
    public bool IsB => _tag == TagType.B;
    public bool IsC => _tag == TagType.C;
    
    public Test(A a)
    {
        _tag = TagType.A;
        _value = a;
    }
    
    public Test(B b)
    {
        _tag = TagType.B;
        _value = b;
    }
    
    public Test(C c)
    {
        _tag = TagType.C;
        _value = c;
    }

    public override string ToString() => _tag switch
    {
        TagType.A => $"Test.A({(A)_value})",
        TagType.B => $"Test.B({(B)_value})",
        TagType.C => $"Test.C({(C)_value})",
        _ => 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;
        isB = IsB; 
        isC = IsC;
    
        a = isA ? (A)_value : default!;
        b = isB ? (B)_value : default!;
        c = isC ? (C)_value : default!;
    }

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

Given these patterns we would know that the a, b or c we are unwrapping cannot be null as the isA, isB and isC flags are true I think just returning non nullable from the deconstruct makes sense but maybe some special handling to ensure a user can't actually deconstruct the Test manually, only the compiler can:

if (test is (true, var a, _, _, _, _)) Console.WriteLine(a);
if (test is (_, _, true, var b, _, _)) Console.WriteLine(b);
if (test is (_, _, _, _, true, var c)) Console.WriteLine(c);

[ScottKane]

This is technically already possible in C# so adding unions should just be some lowering sugar to make working with it nice.

This is not possible without additional runtime support, otherwise you will encounter consistency and correctness issues. Consider:

Is<Test>(new A());

bool Is<T>(object obj) => obj is T; // the compiler doesn't know anything about Test here so the code would return false instead of true.

Would you expect new A() is Test to be true?

I would expect new Test(A()) is Test to be true or new Test(A()) is Test.A(_)

Or given an object obj is Test.A(_) should be true.

Console.WriteLine(new Test(new A(1)) is Test);
Console.WriteLine(new Test(new A(1)) is (true, _, _, _, _, _));

True
True

object obj = new Test(new A(1));
object obj2 = new Test2();
Console.WriteLine(obj is Test);
Console.WriteLine((obj as Test?) is (true, _, _, _, _, _));
Console.WriteLine((obj2 as Test?) is (true, _, _, _, _, _));

class Test2;

True
True
False

[2A5F]

bool Is<T>(object obj) => obj is T;

Union variant is not a type.

[ScottKane]

In what I am suggesting A, B and C are user defined types but you could have:

union Test
{
    A(A), // User defined A type
    B(B), // User defined B type
    C(int Value1, int Value2, int Value3) // Ad-hoc - just a named tuple underneath
}

[sanamhub]

Will C# union will have ability to infer like below example in TypeScript, or need to explicitly define type first and only can use later?

declare function getAnimal(): Fish | Bird;

I did check on Champion doc, couldn't figure out correctly. perhaps, I misunderstood too

[HaloFour]

No, as of now the type union must be nominally declared as its own type, e.g. FishOrBird. There could be generic containers to help in declaring more adhoc unions, e.g. OneOf<T1, T2>, but without runtime support there really isn't a way to make that behave seamlessly with generics or when boxed as an object.

[mattwar]

C# will likely never have inferred return types on methods. Lambda do, though, so there might be some space for inferring unions there. The problem is that the language already has rules about inferring common types and altering that to infer unions instead would be a major breaking change to the language. There are some ideas floating around though. So maybe.

[HaraGabi]

I might be misunderstanding but I don't think @sanamhub wanted a union to be inferred. I know he used the word, but in his example only the name of the union is inferred. I think he needs the union equivalent of the (Fish, Bird) tuple.

[2A5F]

This is not infer, this is a type level expr

[mattwar]

I see. No worries, nothing has ruled out the existence of anonymous type unions. I do have a proposal in the works that builds on top of the existing nominal type unions proposal.