Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Official proposal for Type Unions in C#

github.com

Post reply on HN
Print view View original

121–130 of 315 posts

Re: Official proposal for Type Unions in C#

#121

Post by jsmith45 »

noelwelsh wrote: post #59
ctenb wrote: post #32

I find it strange and slightly confusing that tey call it "union types". The correct term would be "sum types" or "discriminated union types", union types being the union of two types with no distinctive tag between the two cases. E.g. |Int ∪ Int| ≡ |Int|, while |Int + Int| ≡ 2 |Int|

AFAICT from a quick skim of the proposal is actually includes both sum types (called union types) and union types (called ad hoc unions) under the same proposal. This is, to me, very confusing. They work in very different ways.

At runtime every value of any of these types are tagged in some some way. The struct based ones with an explicit tag member that is not visible at the language level. All the rest by way of the object's runtime type (v-pointer).

Which means the fact that some look at a language level like a traditional closed sum type, and others look more like a union type is pretty much just that, looks. Even the "ad hoc unions" are basically functioning as sum types here, just an ad hoc sum type whose type constructors are other types, and abusing the fact that classes or boxed structs all have a vptr that can be used as the discriminator.

This all compiles down to code that pattern matches on either the explicit tag member, or on the runtime type, and after the pattern match you basically have a normal type to work with. Hence why they are lumping it all together.

Re: Official proposal for Type Unions in C#

#122

Post by munificent »

paulddraper wrote: post #51
ComputerGuru wrote: post #8

Every time the question of preferred programming languages comes up, I'm usually in the extreme minority with my preferences being Rust (for small/fast) and C# (for productive and easy, where GC is acceptable), a combination that doesn't seem to appeal to too many people. But for the projects that fall right about in the middle where it could go either way and I could see either language working, I almost always pick…

> It's incredibly hard to go back to a language without even basic ADTs after seeing the light. How did we ever prioritize implementation inheritance over ADTs? I don't know, but it was a mistake.

I think a similar but perhaps more accurate question is how did we prioritize virtual dispatch over ADTs?

And I think the answer has a lot to do with the expression problem [1] and which kinds of extensibility were needed in the kinds of programs that languages at the time were designed for.

OOP with subtyping and virtual dispatch makes it very easy to define an interface with a set of methods, and then have an open-ended set of concrete classes that all reliably implement those methods. It makes it easy to say "I don't know what data types I'll need yet, but I do know what operations I'll need."

ADTs flip that around. That make it easy to express "I don't know what operations I'll need yet, but I do know what data types I'll need."

For the kinds of simulations that Kristen Nygaard and Bjarne Stroustrup were writing, and then later the large GUI applications that C++ users were building, it seems that the former was more useful than the latter.

[1]: https://journal.stuffwithstuff.com/2010/10/01/solving-the-ex...

Re: Official proposal for Type Unions in C#

#123

Post by munificent »

ctenb wrote: post #32

I find it strange and slightly confusing that tey call it "union types". The correct term would be "sum types" or "discriminated union types", union types being the union of two types with no distinctive tag between the two cases. E.g. |Int ∪ Int| ≡ |Int|, while |Int + Int| ≡ 2 |Int|

The proposal does both sum types and union types.

Re: Official proposal for Type Unions in C#

#124

Post by jeremycarter »

CharlieDigital wrote: post #68
ComputerGuru wrote: post #8

Every time the question of preferred programming languages comes up, I'm usually in the extreme minority with my preferences being Rust (for small/fast) and C# (for productive and easy, where GC is acceptable), a combination that doesn't seem to appeal to too many people. But for the projects that fall right about in the middle where it could go either way and I could see either language working, I almost always pick…

It's possible to add DUs in C# today with some third party packages. - https://github.com/domn1995/dunet - https://github.com/mcintyre321/OneOf Quite good and ergonomic with the source generators removing a lot of the boilerplate. I have a practical example here using OneOf with .NET Channels: https://chrlschn.dev/blog/2024/07/csharp-discriminated-union...

Actually not a bad solution. Thanks for sharing

Re: Official proposal for Type Unions in C#

#125

Post by pipes »

progmetaldev wrote: post #100
djeastm wrote: post #81

Earlier quoted context omitted.

>You're going to have patterns from the .NET Framework era being ported to .NET Core projects. It works, but you'll have two paradigms of doing things mixed into your project. I've been spending the past couple years migrating various platforms from Framework to the new .NET and as long as you've got a head on your shoulders it's not too bad. Also, new projects in .NET are fantastic to work with, imo.

I have been doing the same, but I would be willing to bet that you're probably more disciplined than the average .NET developer (or at least have taken the time to learn more than just the surface features available). In my experience, most .NET developers don't take the time to really learn the framework (whether traditional .NET Framework, or the Core framework). It is a great feeling once you've got a Framework pr…

Genuine question, what do you mean by "learn the framework" ? (I mainly work with c#, I constantly worry I am not proactive enough in my learning).

Re: Official proposal for Type Unions in C#

#126

Post by munificent »

Alifatisk wrote: post #76

Even dotnet is looking at implementing type unions, why can't Dart finally agree on adding this aswell!?

We added sum types and exhaustive pattern matching in Dart 3.0.

Union types (what the proposal here calls "ad hoc unions") are a separate, much harder feature whose value proposition is less clear. The cost of adding a new kind to the type system is quite large because it impacts method resolution, overriding, type inference, subtyping, least upper bound, generics, type promotion, etc.

It can be worth it (for example, we added tuple/record types in Dart 3.0), but the value proposition must be correspondingly high to justify it. It's not clear that union types meet that bar yet. In many if not most of the places where users are asking for it, it often seems like what they really want is overloading or some other feature.

Re: Official proposal for Type Unions in C#

#127

Post by tester756 »

LAC-Tech wrote: post #98

I always think it's a shame that instead of C# becoming a better OO language, they keep trying to become an uglier F#. IE, why is the syntax for multiple dispatch still so clunky? I know I know, pseudo OO took over the world, and then people revolted against it, so the easiest thing to do to stay relevant is to become "slightly functional with curly braces", rather than to actually try and do OO well.

What does "better OO" mean here?

Which concepts or feature you have on mind?

Re: Official proposal for Type Unions in C#

#128

Post by xeromal »

bbkane wrote: post #119
xeromal wrote: post #97

Earlier quoted context omitted.

My brain really likes how organizes C# libs tend to be compared to the 50 different organization schemes I deal with in node and python

Does C# impose a lot of organization? I've only worked in one C# codebase but it has partial classes everywhere and TONs of abstraction bloat. I found it difficult to reason about the organization.

I don't think I've really seen a partial class since the webforms/winforms days about 15 years ago. Maybe XAML too but I haven't used XAML in so long.

I think abstraction bloat is one of those things that's a preference. What's bloat to one is organization to someone else. When I hope into a python codebase and it's 900 line file doing computer vision madness, I hope and pray for abstraction bloat. I'm sure there are countless c# bloated codebases but I think that's mostly a function of c# codebases being inside megacorporate or government codebases. The bloat comes from the general inefficiency that those companies run at. I guess the same could be said by the scrappy python startups that put everything in a single file with no types or inversion of control or OOP.

I guess I'm saying that I'd rather deal with the bloat problem than the wild west problem. lol

Re: Official proposal for Type Unions in C#

#129

Post by ygra »

SideburnsOfDoom wrote: post #20
wackro wrote: post #18

What would the rough timeframe be for seeing adoption of this into the language? I was considering introducing the OneOf library into our codebase, but if this is < a year or so away it might not be worth the effort.

The linked says "Proposed, Prototype: Not Started, Implementation: Not Started, Specification: Not Started" .NET releases are every November, and I would be very surprised to see this in November 2024. More likely November 2025 at soonest. But check back to that page later.

Definitely no way for Nov 2024 since they're already no longer merging features for that release. Considering the scope of this, I'm doubtful for next year as well. .NET takes their time with features to get them right as well. They don't seem to take as long as Java, but maybe most new features are also not as widely publicized.

Re: Official proposal for Type Unions in C#

#130

Post by progmetaldev »

pipes wrote: post #125
progmetaldev wrote: post #100

Earlier quoted context omitted.

I have been doing the same, but I would be willing to bet that you're probably more disciplined than the average .NET developer (or at least have taken the time to learn more than just the surface features available). In my experience, most .NET developers don't take the time to really learn the framework (whether traditional .NET Framework, or the Core framework). It is a great feeling once you've got a Framework pr…

Genuine question, what do you mean by "learn the framework" ? (I mainly work with c#, I constantly worry I am not proactive enough in my learning).

I mean the built-in libraries for .NET (whether that is the older .NET Framework, or .NET Core - now labeled just as .NET). One of the biggest benefits to using C# and .NET is the amount of documentation available. If you are still using .NET Framework, and haven't moved to the open-source .NET, I would suggest spending some time learning the open-source version. It's not vastly different, and the good thing is the C# language hasn't changed very much, other than adding new features for developer ergonomics.
Post reply on HN