[LDM] - Type Unions Proposal

[mattwar]

This proposal is being presented to LDM today. It is not a plan or record. It has not yet been accepted. When it, or equivalent is accepted it will go through many changes before becoming an actual feature. Your feedback is welcome and expected.

Type Unions in C#

I or other team members will probably be able to answer questions later today.

[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?

[vladd]

Taking erasure into consideration, I wonder if following would be possible:

bool IsA<T>(object o) => o is T;
bool isIntOrString1 = IsA<int or string>(5); // expected true
bool isIntOrString2 = IsA<int or string>(DateTime.Now); // expected false

[DavidArno]

I don't know what we're arguing about then as again it seems like we're on literally the same page...

Allow me to summarise:

Your position: you desire Dus and want them soon. If there's a need, type unions can follow. Type unions should respect transitivity. (I'm unclear on whether you think tag unions should too). There is no need (or you think it undesirable, I'm unclear on this point as well) for special ad hoc union syntax.

My position: unions and unions. Tags are a special case feature to differentiate between two cases of the same type. Therefore, having separate solutions for unions needing tags from those not needing them is likely a colossal waste of time. Transivity would be nice, but not essential. Adhoc union syntax would be useful, but not essential and it would be a bonus if that syntax could handle tags too.

[HaloFour]

@DavidArno

Tags are a special case feature to differentiate between two cases of the same type. Therefore, having separate solutions for unions needing tags from those not needing them is likely a colossal waste of time.

I'm a little confused by these statements. All unions proposed here are tagged unions, whether that tag is implemented by an int flag in the type or the object header on the heap. Either way, you can't declare a union of existing types like int or string, you need to declare tag types (e.g. Choice1Of2) to contain those types as data elements.

The only version of union in the proposal that isn't a tagged union are adhoc type unions, which is where (int or long) encodes down to object.

[DavidArno]

Again, it's all compromises. The solution that Matt is proposing is that all named union types must use tags and adhoc types cannot have tags. That works for me.

I'd like to be able to be able to define:

union U 
{
    int,
    string
}

as no tags are needed there, but the proposal allows me to do:

using U = (int or string);

Not as elegant, but it does the job.

An ideal implementation would allow:

union Maybe<T>
{
    None, // tag with no type
    T // type with no tag
}

but that's complex and not really needed as a tag can be used:

union Maybe<T>
{
    None,  
   Some( T value) 
}

The resultant patterns aren't different enough to care the lack of the first version:

if (maybe is T value ...
if (maybe is Some value ,,,

The two enhancements that I'd like in a v2 is the ability to use the ad hoc notation to specify tags:

private (double length or double area or double volume) GetMeasurement(...

and the ability to declare named unions with no tags but they are bonus features and far from needed.

So I'm happy with the proposal. It's near enough to the "unions are unions" position for me to not care about the details. As for "(int or long) encodes down to object", whilst some here likely will vociferously disagree with me, to my mind this is mere implementation detail. Unless the fact that it's an object underneath leaks out eg through a pattern match claiming it's not exhaustive, then I don't care how it's implemented other than being mindful not to use adhoc unions in performance critical situations.

[CyrusNajmabadi]

to my mind this is mere implementation detail.

it's not an implementation detail. It's a part of the ABI contract for these types.

[vladd]

@CyrusNajmabadi

So people would need to keep in mind "ad hoc unions are broken in some aspects".

Just like tuples. You've just decided arbitrarily that the way they are broken is actually something you are fine with, and thus it's ok. That's fine. You're welcome to your opinions on that. But we can debate and end up feeling differently to you on this.

Of course, this all is just a personal opinion. We are expressing only personal opinions here, after all.

But anyway, my personal opinion is that the adhoc unions could be widely used in real world scenarios (e. g.: DTO, where the value can naturally be number or one of predefined enum values). I would expect this pretty typical code:

bool TryGet<T>(object o, out T t)
{
    if (o is T t1) { t = t1; return true; } else { t = default; return false; }
}

class C
{
    public (int or SpecialEnumValue) Field;
}

C c = new();
if (TryGet<(int or SpecialEnumValue)>(dict["Property"], out c.Field)
{
    // work with Field
}
else
{
    // report error
}

to run without any evil surprises (which are guaranteed with erasure).

My personal opinion is that without proper generic support feature would be much less useful, and there will be no possibility to improve the adhoc unions later.

One can say that the dynamic would be equally broken. But dynamic is a rather niche feature which is not widely used in mainline C# programming. One can say that class tuples were replaced later with much better anonymous tuples (so "bad" adhoc unions may be later replaces with "better" ones). But the original tuples had inferior syntactical representation, so it was pretty easy to deprecate them. One can say that the value tuples have erased names (so they are equally non-perfect). Although that is true, losing the names of tuple fields comparing to false positive in type check is a really minor and neglectable glitch.

My personal opinion is that not implementing the proper type check makes the adhoc unions broken.

[WashingtonARamos]

Given we're gonna have a Result<T,E> type, could we also have an error propagation operator? Experimenting with a Result<T,E> type that my team and I use on our project we've realized it can be very cumbersome evaluating many calls that return a Result type. We're often checking if (myResult.IsSuccessful) and acting upon it like so:

public Result<ClientData> GetClientData()
{
    var orders = GetOrders();
    if (!orders.IsSuccessful)
        return orders.Error;
    var personalData = GetPersonalData();
    if (!personalData.IsSuccessful)
        return personalData.Error;
    var shoppingCart = GetShoppingCart();
    if (!shoppingCart.IsSuccessful)
        return shoppingCart.Error;
    return MapClientData(orders.Value, personalData.Value, shoppingCart.Value);
}

Since GetOrders, GetPersonalData and GetShoppingCart all return a Result that may be an Error type common to them all, it could be much cleaner simply writing:

// ?? checks if the returned type of a Result<T,E> is T or E. If T then the value is asssigned
// to the left-hand variable. If E, the error value is immediatly returned to the caller.
public Result<ClientData> GetClientData()
{
    var orders = GetOrders()??;
    var personalData = GetPersonalData()??;
    var shoppingCart = GetShoppingCart()??;
    return MapClientData(orders, personalData, shoppingCart);
}

Of course this is pseudo-code as ?? is already taken as null-coalescing operator, but wouldn't it be nice to have an error propagation operator somehow?

[hamarb123]

I do think we should consider making ?? work for Result.Error in a similar to how it works today for say null.

I tend to mostly agree with Jared.

Can't wait to write

Result<int?, Error2>? a = ...;
var i = a ?? Some(null) ?? null ?? 0; //get the int value or 0

😁

I do think a preserve null/error operator could be quite useful though, as this is something I've written many times will null already today:

int? x = ...; //move to local as there's no easy way otherwise
long? y = x == null ? null : (long)x.Value + 1;

//similar concept for Result
Result<int, Error> x = ...;
Result<long, Error> y = x switch
{
    Some(var v) => Some((long)v + 1),
    Error(var e) => Error(e),
};

Not exactly sure what the syntax could be though.

Also, if we add special syntax support to Result (which I'm not sure if/how much we should do this), then I don't see why Option should not get whatever that syntax is too personally. It's potentially even more useful on Option, as I imagine we'll get tonnes of people saying "why can't I do o?.Method like I can with Nullable?" for example.

[Joe4evr]

@jaredpar

Thus far we've gotten away without having an operator that silently returns from a method when encountering those values. What about Result makes it special that we should doing this?

IMHO Result is not special enough to warrant this type of new operator. I think our existing control flow mechanisms are fine for this.

I totally agree with you, but it would still be very nice if there's a convenient way (either an API call or possibly as a special understanding by the compiler) for a more limited set of conversions. Primarily converting a Result<T, Error>.Failure (so statically known to be the Failure case) to any Result<U, Error>.Failure. Error propagation is a key part in the coding style for these kinds of types, so having a quick way to do the unwrap->rewrap of the Error value (as long as that type argument matches) would save a decent bit of tedium.

public Result<long, Error> Example()
{
    Result<int, Error> x = ...;
    // if the compiler gets special knowledge it could be as simple as this:
    if (x is Failure f) return f; // lowered as 'return new Result<long, Error>.Failure(f.Error);'

    // otherwise, a simple method could suffice (name TBD):
    if (x is Failure f) return f.ValueAs<long>();

    //......
}

Same goes for converting Option<T>.None->Option<U>.None (probably even easier since the None case carries no additional state).

This does start begging for a solution to the flip-side scenario: Converting T->U either for values statically known to be Success/Some, or on the "parent" unconditionally. If that can be made to work about as nicely as Failure/None described above when T : U (basically imitating covariance on T, I've written another reply in this discussion about that already) that also saves tedium, but that still is only a subset of situations and needs thought on defining what happens when T can't convert to U.

[orthoxerox]

On the one hand, having a shorthand for returning the Error/None part could be useful, but on the other hand, this basically treats Result/Option as exceptions (check yourself, the code looks identical modulo extra sigils), and writing this code with exceptions is already possible.

I would rather extend the semantics of ?? ?. and ?[ to cover these types (cough #147 cough). This is a more C#-like change.

[CzechsMix]

On the one hand, having a shorthand for returning the Error/None part could be useful, but on the other hand, this basically treats Result/Option as exceptions (check yourself, the code looks identical modulo extra sigils), and writing this code with exceptions is already possible. - @orthoxerox

No it is not "basically exceptions." Exceptions are expensive to build and throw, and if you call a function that throws an exception the compiler doesn't do anything to force you to handle said exceptions.

This makes it harder for developers to write code that handles errors, since it may not be obvious which errors are even able to be thrown.

This also make it harder for developers to test error cases, since you can't simple call a function and then see if the return value is the expected Error.

[HaloFour]

I do think that it's helpful to frame/view the conversation as a desire to use Result<...> as lightweight exceptions, and this particular ask is to support "bubbling up" that exception. I do think that the Rust mechanism to "unwrap" the Result<...> and support an early return is probably more C#-ish than comprehensions and trying to bend LINQ to feel more natural over general monads. You can kinda view async/await as already having that same mechanism, even though it is built on top of exceptions under the hood. Maybe it's more palatable in a language design sense if it is built in that same way, where "unwrap" throws, but if it does so outside of a try block the compiler is free to optimize to avoid the intermediary exception.

[chtenb]

This proposal generated some discussion on Hacker News, and many people's first response (including my own) was about how the term "union type" as a catch all term seems incorrect or confusing. Union Type is not a passable abbreviation for a Discriminated Union Type. "Sum type" would be a more commonly used term here.

In contrast, what the proposal currently calls "Ad Hoc Union Types" really does seem to be a union of types, so here the term "union type" seems very appropriate.

Would it be possible to amend the proposal with clearer terminology, reducing the amount of confusion?

[johnazariah]

Agree with Jared here... I'm totally not in favour of special operators for any more types. What would work nicely - but is a moon-shot at this point - is some syntactic sugar for monadic bind, which would deal consistently with types like Option (and Result, and Task, and List, and other types) used to compose function invocations...LINQ is available but a bit clunky, and we have already too many special operators in the language... Other languages have simplified and normalized the approach to composing functions that return these kinds of types, and they turn out to be quite easy to learn and elegant to use...

…

-John

On Fri, 9 Aug 2024 at 08:22, Jared Parsons ***@***.***> wrote: Then maybe the main question here is: could we have an implicit return operator that could be used by Result<T,E> for error propagation? This is where I will keep pushing the "why is Result special?" C# is 20 years old, it has a variety of ways to represent *error* scenarios in value the most common of which is null. Thus far we've gotten away without having an operator that silently returns from a method when encountering those values. What about Result makes it special that we should doing this? IMHO Result is not special enough to warrant this type of new operator. I think our existing control flow mechanisms are fine for this. I do think we should look at operators like ?? and adapt them for Result. But I don't think it warrants an entirely new class of control flow. — Reply to this email directly, view it on GitHub <#8313 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGKWZZSH5DOM6FAB55DKNLZQPVTFAVCNFSM6AAAAABLM3DJRGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMRYGAZTGMI> . You are receiving this because you commented.Message ID: ***@***.***>

-- *John Azariah* *m *+61 421 100 747 *e* ***@***.*** *t* @johnazariah <http://twitter.com/johnazariah> [image: See the source image]

[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?.