[Discussion]: Unions #9663
Replies: 11 comments 54 replies
-
*existing, I assume |
Beta Was this translation helpful? Give feedback.
-
|
What is the purpose for having the |
Beta Was this translation helpful? Give feedback.
-
|
Does exhautiveness work for "partial" unions (a "sub-union")? A related question, can we return a sub-union? |
Beta Was this translation helpful? Give feedback.
-
|
for my opinion add static multi-inheritance for struct other cases we can resolve with [Offsets] |
Beta Was this translation helpful? Give feedback.
-
|
What about this syntax, since C# has recently added the keyword union Pet allows Cat, Dog, Bird;
closed record Pet2 allows Cat, Dog, Bird;I feel no conflict having commas once the parens are gone, interestingly. |
Beta Was this translation helpful? Give feedback.
-
|
Isn't it possible to make a tagged union implementation behind the scenes when all of the cases are struct types, and maintain the same surface area? Basically, |
Beta Was this translation helpful? Give feedback.
-
|
It feels like the non-boxing pattern which is proposed here, is also requiring a "sequence of type tests", calling the TryGetValue methods one-by-one. I wonder if in a future revision of the feature, it would be possible to have an O(1), non-boxing dispatch, by using a switch over System.Type (#356). Switching over System.Type was proposed some time ago but I don't think was ever implemented in the language or runtime. struct MyUnion : IUnion, IUnion<int>, IUnion<bool> { ... }
var myUnion = new MyUnion(true);
switch (myUnion)
{
case int i: ...;
case bool b: ...;
}
// lowered to?
switch (myUnion.GetValueType())
{
case typeof(int): int i = myUnion.IntValue; ...;
case typeof(bool): bool b = myUnion.BoolValue; ...;
}I am just not sure how |
Beta Was this translation helpful? Give feedback.
-
|
You could do exact type switch and then on failure fallback to slower type match. |
Beta Was this translation helpful? Give feedback.
-
Compatibility of proposed union syntax with potential future anonymous unionsCurrently, anonymous unions are out of scope. Is there any possibility they might be added in the future? If not, please disregard this post. Anonymous unions would be useful for method return types and method input parameters. Current proposed union syntax is
Omitting And for other syntaxes discusses in LDM-2025-09-29, using short syntax without the Syntaxes in which the type list is not surrounded by any kind of delimiter don’t seem to work well with anonymous unions, so I’ve added only one example. To me, the easiest to read is |
Beta Was this translation helpful? Give feedback.
-
|
My team are interested in this feature - working in a Typescript frontends and C# backends company there's significant difficulty being proficient in both languages especially when they have features that look similar but are different. From reading the proposal and discussion, and watching the announcement video, I understand this will be one of those features. I've got a few concerns that I'm wondering how or if they will be addressed.
Our team was interested in trying this approach, and used the OneOf library to get used to the idea of unions in C# for this purpose. There's real benefit (actually knowing, with type safety, all the possible response types in our minimal api definitions!) but the ergonomics are painful when you pass unions through layers of services. If
You know this wouldn't compile since I may be misreading the proposal but using the pattern matching switch is the only way to deal with union possibilities, and with that, you cannot perform an early return. OneOf provides a Switch method - but it suffers the same inability to early return due to using lambdas. Your stuck with successively peeling off one value at a time - which explodes the amount of code needed and sets off all kinds of code quality alarms. Is there any way in the given proposal to ergonomically change the control flow based on the value in a union? The most ideal would be something like:
The simplest approach I see is syntax like: or But that implies that either
I know that it's maybe out of scope, or maybe this is something best left up to code gen wizards as an aftermarket thing, but it would be great if there was something typesafe and ergonomic. I know that implicitly casting is off the table as per the spec but maybe explicit doesn't have to be so bad either. Maybe even just a naive "if the target union has an explicitly defined case for the cast union cases and the cast union cases are all explicitly defined, then the cast is valid, otherwise the compiler throws an error. |
Beta Was this translation helpful? Give feedback.
-
|
I haven't seen any mention of F# discriminated unions in any of the LDM notes or discussions. Would there be any compatibility or interoperability? How do the implementations compare? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Several union proposals were consolidated into one. Here is a place to discuss the one.
Proposal document:
https://github.com/dotnet/csharplang/blob/main/proposals/unions.md
Issue for proposal:
#9662
Beta Was this translation helpful? Give feedback.
All reactions