upvote

points

by mwkaufma7 hours ago |
comments
upvoteby functional_dev5 hours ago|
next
[-]
Right, the default boxes into heap, but unions are different. Some languages pack them as a flat struct (tag + payload, no allocation).

Here is visual layout if anyone is interested - https://vectree.io/c/memory-layout-tagging-and-payload-overl...

reply
upvoteby debugnik52 minutes ago|
parent|
[-]
That is not what C# has just added to the language though. These union types so far are just wrappers over an `object` field which gets downcasted.

F# offers actual field sharing for value-type (struct) unions by explicitly sharing field names across cases, which is as far as you can push it on the CLR without extra runtime support.

reply
upvoteby AndrewDucker7 hours ago|
prev|
next
[-]
Yes, but see the section on custom unions* - you can write non-boxing unions/generators.

* https://devblogs.microsoft.com/dotnet/csharp-15-union-types/...

reply
upvoteby mwkaufma5 hours ago|
parent|
[-]
Yes, there's a compat-shim in the stdlib/runtime, but not in the language syntax. E.g. it by-definition won't do escape-analysis and optimize discriminated value-types with the first-class keyword.
reply
upvoteby Izikiel431 hours ago|
parent|
[-]
For now
reply
upvoteby celeries7 hours ago|
prev|
[-]
Yes, but that's just the default behavior. You can implement your own non-boxing version for performance critical applications.
reply
upvoteby algorithmsRcool4 hours ago|
parent|
[-]
Why on earth did they decide boxing by default was a sensible design decision...

We have been pushing toward higher performance for years and this is a performance pitfall for unions would are often thought of as being lighter weight than inheritance hierarchies.

F# just stores a field-per-case, with the optimization that cases with the same type are unified which is still type safe.

reply
upvoteby Metasyntactic1 hours ago|
parent|
next
[-]
Hi there! One of the C# language designers here, working on unions. All the different options have tradeoffs. As an example, the non-boxing options tear, which can be problematic. And, we have a lot of experience implementing the simple, reference-type, approach for types that make a lot of sense to people, but then adding a lightweight, value-type version for people who care about that later. See tuples, as well as records.

I expect the same will old here. But given the former group is multiple orders of magnitude higher than the latter, we tend to design the language in that order accordingly.

Trust me, we're very intersted in the low-overhead space as well. But it will be for more advanced users that can accept the tradeoffs involved.

And, in the meantime, we're designing it in C#15 that you can always roll the perfect implementation for your use case, and still be thought of as a union from teh language.

reply
upvoteby debugnik45 minutes ago|
parent|
prev|
next
[-]
> with the optimization that cases with the same type are unified which is still type safe.

To be clear, this requires explicitly using the same field name as well.

reply
upvoteby zigzag3123 hours ago|
parent|
prev|
[-]
From what I've read, this is for the first implementation of unions, to reduce amount of compiler work they need to do. They have designed them in a way they can implement enhancements like this in the future. Things like non-boxing unions and tagged unions / enhanced enums are still being considered, just not for this version.
reply
upvoteby CharlieDigital2 hours ago|
parent|
[-]
This is the general pattern of how the C# team operates, IME.

    "Never let perfect be the enemy of good"
Very much what I've seen from them over the years as they iterate and improve features and propagate it through the platform. AOT as an example; they ship the feature first and then incrementally move first party packages over to support it. Runtime `async` is another example.
reply