.NET (OK, C#) finally gets union types

https://andrewlock.net/exploring-the-dotnet-11-preview-2-dotnet-gets-union-types/

by ingve • 2 months ago

237 273 2 months ago

munchler6• 2 months ago

F# leads the way and C# slowly catches up, as always. Yet for some reason, C# still gets all the mindshare.

Haskell, OCaml, Erlang lead the way and Rust, Zig and Go get all the mindshare. I feel like its a common pattern for more experimental languages to pioneer features and other languages to copy the features and bring them to a C style syntax that the majority of devs are familiar with.

cultofmetatron• 2 months ago

Rust and Zig brought new ideas for memory management that Haskell, OCaml, Erlang sidestep having garbage control. its honestly amazing to me that they managed to get the adoption they have while being so innovative. I say this as a fulltime elixir dev.

jiggawatts• 2 months ago

I wish I could find the reference, but there was a great blog / article by a computer science academic basically saying that OO, procedural, and functional paradigms are extremes of a design space where the “middle” of its Pareto frontier was essentially unknown until recent advances.

Moreover, many functional languages are getting pseudo-procedural features via the like of “do” syntax and monads, but that this is in some sense a double abstraction over the underlying machine that is already inherently procedural.

Starting from a language that is already procedural and sprinkling some functional abstractions on top is simpler to implement and easier for humans to use and understand.

Rust especially showed that many of the supposed advantages of functional languages are not their exclusive domain, such as sum types and a powerful type system.

Update: Hah! ChatGPT found it: https://news.ycombinator.com/item?id=21280429

Note the top comment especially, which explains succinctly why functional has rather substantial downsides.

skybrian2• 2 months ago

Being first isn't necessarily good if you get it wrong, though. Laziness by default and Hindley-Milner type inference seem like mistakes that simply aren't going to get cleaned up. Other languages make their own mistakes too.

jen20• 2 months ago

The idea that Erlang is experimental is pretty amusing- it’s one of the most stable platforms there is.

hvb2• 2 months ago

I feel like its a common pattern for more experimental languages to pioneer features and other languages to copy the features and bring them to a C style syntax that the majority of devs are familiar with.

You're ignoring the fact that it's harder to bring new features to older languages as they have more bloat to deal with as not every idea turns into a success. So younger more focused languages can iterate more quickly. Also, being willing to make breaking changes makes things easier. Microsoft tries hard not to do that with C#.

Over time, maintaining any software becomes harder, languages are no exception. The fact that c# is still around, and still being developed is a feat in itself

nullhole• 2 months ago

What types of problems are better solved in F# than C#?

Is having a combination of F# and C# in a single codebase possible? Is it recommended?

moron4hire• 2 months ago

It's very possible, even encouraged when you have workloads that call for it. F# is a great functional language, so it's good for parsers, compilers, etc. The support for units of measure is also really cool, making it great for scientific computing.

Akronymus3• 2 months ago

Easy code is much easier in f#, a lot of the time. Hard code is usually easier in f# due to the type system helping a lot. F# is also a lot more concise.

And yes, you can combine them, but afair, only in terms project boundaries. (You can include a c# project in an f# one and vice versa). There are a few cases where it's quite useful. For example, rewriting a part of a big project in f# to leverage the imperative shell - functional core architecture. Like rewriting some part that does data processing in f#, so that you can test it easier/be more confident in correctness, while not doing a complete rewrite at once.

Sort of like rust parts in the linux kernel.

bertylicious7• 2 months ago

I don't think it's a matter of the type of problem and I always found it weird how F# is being framed as being only useful for "math-heavy" problems.

What matters is what libraries you are gonna use for your solution. If most of them are C#-only and don't have an F# equivalent then you'll lose the ergonomics and conveniences that make F# so easy to work with.

munchler6• 2 months ago

All types of problems. F# can do almost anything C# can do and with less ceremony. The quote I like is that once you get comfortable with F#, switching back to C# is like "having to fill out government forms in triplicate".

nozzlegear• 2 months ago

I love F#. It's my go-to language and one that I work with every day. Personally I feel that IDE support (as in perf, QoL features, etc.) is the only area it lags behind C#, and outside of that it's a clear winner for everything that I want to do with it.

pjmlp13• 2 months ago

Microsoft management has decided CLR has a new meaning, C# Language Runtime.

VB, C++/CLI and F# are only there because existing customers.

They have always behaved as if it had been a mistake to promote F# from research project into VS 2010 as an official language.

Since then it has been something that the teams never knew how to sell to the .NET customer base, pivoting from being only libraries for C# and VB, write unit tests, Web development, data analysis, whatever might make it.

However it was Standard ML, Miranda, Hope, OCaml and Haskell that lead the way, we aren't still fully there.

teh_klev• 2 months ago

Microsoft management has decided CLR has a new meaning, C# Language Runtime. VB, C++/CLI and F# are only there because existing customers.

Oh, I think we need a citation for these claims.

bob10293• 2 months ago

C# gets all the mindshare because it's easier to understand and use on average.

We can all agree that F# is more clever and concise. No one is dying on that hill. But in terms of hacking your way through the customer requirements and working with a team of other humans, it cannot hold ground in the same way.

There is certainly not some concerted effort or lack of care involved. Microsoft could 10x the marketing budget around F# and the adoption rate probably wouldn't budge.

xigoi4• 2 months ago

I hate the trend of measuring “easy to understand” based on how superficially similar the language is to C/Java.

ShalokShalom4• 2 months ago

That is entirely anecdotal and based on subjective interpretation of someone, who has worked in C like languages or something similar:

This is just about how you are used to it, it says nothing about the quality of the language itself.

hahn-kev3• 2 months ago

I'm glad to finally see this making it's way into C#. Not so much because I want to use unions purely in C#. But because I want to be able to define them when interfacing with other languages.

Quarrelsome12• 2 months ago

I mean yes, but also: uh-oh. I'm looking forward to reading some code that is even more confusing than the code I'm already reading.

Not entirely convinced that I see the usecase that makes up for the potential madness.

vips7L4• 2 months ago

Union/sum types are generally a good thing. Even Java added them. They tend to be worth “the madness”. Now the rest of all the crazy C# features might be a different question.

dgellow5• 2 months ago

What features do you see as crazy?

munchler6• 2 months ago

Unions are simpler than subclasses and more powerful than enums, so the use cases are plentiful. This should reduce the proliferation of verbose class hierarchies in C#. Algebraic data types (i.e. records and unions) can usually express domain models much more succinctly than traditional OO.

Quarrelsome12• 2 months ago

so the use cases are plentiful

such as?

This should reduce the proliferation of verbose class hierarchies in C#

So just as an alternative for class hierarchies? I mean good people already balance that by having a preference for composition.

weinzierl• 2 months ago

A common use case for the sum type is to define a Result (or Either) type. Now, C# not having checked exceptions is not as much in need for one as Java is, but I could still imagine it being useful for stream like constructs.

Quarrelsome12• 2 months ago

yeah this is the one I've considered as being mildly compelling. But don't we lose the fun of having exception handling as separate to the happy path?

Sharlin• 2 months ago

Discriminated union types are a really fundamental building block of a type system. It's a sad state of matters that many mainstream languages don't have them.

Quarrelsome12• 2 months ago

ok, so what problems do they help me solve that I can't already solve? Is it just that we can make code more concise or am I missing a trick somewhere?

cubefox7• 2 months ago

Discriminated union types are a really fundamental building block of a type system. It's a sad state of matters that many mainstream languages don't have them.

"Non-discriminated" unions (i.e. untagged unions) are even less supported. TypeScript seems to be the only really popular language that has them.

andix• 2 months ago

I've never been confused by language features. Usually the architecture or extreme indirection of the code is the confusing part.

zoogeny2• 2 months ago

This is a classic debate in programming, literally:

2001: "Beating the Averages" (Paul Graham) [1]

2006: "Can Your Programming Language Do This?" (Joel Spolsky) [2]

Both of these articles argue for the thesis that programmers that have been deprived of certain language features often argue that they don't need those features since they are already comfortable working around the lack of said features.

It's a fancy way of arguing: you don't know what you're missing because you've never had it. Or, don't knock it until you try it.

Consider, is your argument a) I've never used it and don't see a need for it, or b) I've used it before and didn't get any benefit?

1. https://paulgraham.com/avg.html?viewfullsite=1

2. https://www.joelonsoftware.com/2006/08/01/can-your-programmi...

Quarrelsome12• 2 months ago

I can already do functional programming like map/reduce in C# tho. Not sure what the LISP argument is. Spolsky was saying there's a perf benefit in there somewhere but I'm not seeing how unions give me that.

bertylicious7• 2 months ago

Have you considered trying them out (maybe in F#) to understand why they are so popular in many other languages?

moomin2• 2 months ago

AFAICT, this means you won’t be able to define Either<string, string>, which is definitely a thing you sometimes want to do.

throw12345678912• 2 months ago

but can you define T1 and T2 of string, then use Either<T1, T2>?

eterm2• 2 months ago

Could you be clearer about what you mean, since string is a sealed type in C#, so what exactly do you mean T1 and T2 of string?

jzebedee• 2 months ago

C# is strongly-typed, not stringly-typed. The point of the union is to list possible outcomes as defined through their respective types.

The idiomatic way to do this would be to parse, don't validate [1] each string into a relevant type with a record or record struct. If you just wanted to return two results of the same type, you'd wrap them in a named tuple or a record that represented the actual meaning.

[1] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

nesarkvechnep2• 2 months ago

I guess C# is more strongly-typed than Haskell then... /s

sheept• 2 months ago

It seems like if you wrap both in a record then it should be possible:

    public record Left<T>(T Value);
    public record Right<T>(T Value);
    public union Either<L, R>(Left<L>, Right<R>);

goto114• 2 months ago

Well it is a type union. The union of string and string is just string.

bertylicious7• 2 months ago

No, it's a union of a left value (that happens to be a string) and a right value (that happens to be a string). But the compiler-generated code can't tell them apart.

twodave• 2 months ago

You can use implicit operators or a library like Vogen to accomplish the same thing in a way that they can be coerced as strings. This isn’t a real issue.

Metasyntactic5• 2 months ago

Hi there. One of the C# lang designers here.

You're correct. The unions we're working on right now are 'type unions'. So the type is inherent in the union distinction, and you would not be able to distinguish that case. That said, we're also looking at full blown discriminated unions (you can look at one of my proposals for that here: https://github.com/dotnet/csharplang/blob/main/meetings/work...), which would allow for that. Syntax entirely tbd, but you'd do something like:

  enum struct Either<T1, T2> // or enum class
  {
     First(T1 value),
     Second(T2 value)
  }

We view these features as complimentary. Indeed, if you look at the extended enum proposal, you'll see it builds on top of unions and closed types (another proposal coming in the next version of the lang).

moomin2• 2 months ago

Thank you! Even what’s there is going to be really useful to me but I’ll continue to look forward to a full-fat implementation.

le-mark• 2 months ago

I used to see some excitement around .net core several years ago. I haven’t heard or seen much in the wild. Is anyone using .net on systems other than windows nowadays?

dgellow5• 2 months ago

It’s huge in the game dev world, with Unity and Godot. .net also had a reasonable community on mobile for a while thanks to Xamarin, but I cannot imagine that many people using it for new mobile projects in 2026 (outside of game dev I mean).

It’s a very decent language (I mean C#) and runtime, I wish it had more market share in the startup world.

smlavine• 2 months ago

An enterprise shop I co-op'd at was porting one of their apps from Xamarin to MAUI when I worked there, but certainly it doesn't have much mindshare (if any) amongst SE undergrads at my university.

Rohansi7• 2 months ago

Unity is still using Mono these days which is missing basically all of the C# and .NET improvements from the past... 10 years now?

Godot was using Mono too but has since switched to .NET in version 4.

Still a great language and I hope Unity can hit their target to switch to .NET soon!

forgotaccount3• 2 months ago

Yes, lambda's and our dev's use mac's so it enables that. We deploy some apps to some unix based server as well but the company is mostly windows servers anyway.

yread• 2 months ago

Wwwuuuuuaaahhhhh! (making a big wild excited noise using asp.net core exclusively on Linux servers since 2017)

b65e8bee43c2ed0• 2 months ago

it was an obvious marketing campaign. back then core and blazor were shilled relentlessly, and the artificial excitement died the moment MS moved on to shill vscode and typescript.

companies spend a lot on marketing, and it's not just ads.

bel8• 2 months ago

I consulted for multiple enterprise C# projects in the last 5 years. At least two of them are 1mil+ lines of code each.

All of them run in Linux servers.

Some of them were ported from PHP and Python to C#.

Plus LLMs thrive in strongly typed languages.

Which means C# will keep being very strong in enterprise too. Not only in games where it reigns a large chunk of the market share.

lol768• 2 months ago

Yes; many (Alpine/Debian) containers in K8s on GKE for production rail ticketing infra in the UK.

There's not tons of noise being made because for the most part it all, Just Works and that's fairly boring. Perf, memory usage etc gets better every release. As an ecosystem, I'm pretty happy with it. I reach for other languages for smaller microservices.

gib444• 2 months ago

rail ticketing infra in the UK

You mean Raileasy? Or RDG too? (Just curious about the stack of the wider rail tech infra)

za3faran3• 2 months ago

What's preventing you from using C# for smaller microservices? And what do you reach for?

mrsmrtss5• 2 months ago

For almost 10 years now, we have not published anything .NET to the Windows platform. .NET is more performant on Linux today than Windows, and I would say development is also better there (using Rider). However, we do still have devs who prefer Windows. We have built many critical systems on .NET and they just work, so they may be boring to some of the folks who like to have more excitement from their systems.

glimshe• 2 months ago

I love C# and in every iteration we're getting more and more features to get C-like performance in a lot of scenarios. C# does it really well because if your problem isn't performance/memory-constrained, you can ignore these features and fallback on the language's natural ease of use.

hirvi743• 2 months ago

I daylight as a .NET dev professionally. I completely agree with what you have wrote, but I do not think C# is particularly unique in that regard. I would say many common compiled languages are on the same path, e.g., Swift, Java, Kotlin, etc.. As time progresses, I am finding it harder to justify using C# for a greenfield project.

za3faran3• 2 months ago

As time progresses, I am finding it harder to justify using C# for a greenfield project.

Are you able to elaborate why? Just curious.

kensai• 2 months ago

Do you think by now C# has left Java behind in features and performance?

gfody• 2 months ago

more than 10 years ago, yes

brikym• 2 months ago

It always has.

goto114• 2 months ago

C# was always better than Java as a language. The strength of Java is the ecosystem, and Java being open source and cross-platform from the beginning.

lenkite4• 2 months ago

Java Virtual Threads are a superior paradigm to C#'s async/await and function coloring.

biglyburrito8• 2 months ago

Speaking as somebody that spent 2yrs as a full-time Java dev before returning to the Microsoft stack: yes.

Java’s Optional sucks compared to how C# (and Kotlin) implement support for nullable types. C#’s async/await syntax is better than… however the hell Java says to implement asynchronous calls now (Thread? CompletableFuture? idk, I never figured it out). ffs, Java doesn’t even have support for string templates yet — they added it as a JDK preview feature (JDK 21?) and then removed it before final release.

torginus• 2 months ago

I never liked the C#/Java comparison - Java was designed as a much higher level language, and allows reasoning about low level abstractions a lot less, while doing a ton more optimization in the JIT.

For example, GC escape analysis, automatic lock elision, devirtualization, tiered compilation are fairly recent features in C#, and likely not as mature/powerful.

Or C# has generic specialization, so if your generic param is a stuct, you get a separate implementation, while Java generics work via type deletion.

But in C# you have a ton more synchronization primitives, value types, methods are non-virtual by default etc.

This usually means that expertly crafted C# code can be faster than Java (and more importantly, you can trust the compiler to do the right thing), while if you wrote it exactly like Java, you'd probably end up with slower code.

deadeye• 2 months ago

I wish the syntax looked more like typescript. This will confuse my eyes for a while.

ameliaquining• 2 months ago

It works quite differently from TypeScript, so the syntax used there wouldn't have worked.

rohitsriram• 2 months ago

F# has had this for decades, C# is basically just slowly becoming F# with a C-style syntax. Not complaining though, most teams aren't switching languages so getting these features where people actually work is better than nothing.

jdw642• 2 months ago

C# is my strongest and favorite language. That said, it's frustrating that the C# framework ecosystem lacks solid options. MAUI is especially half-baked, and I'm really starting to doubt whether I should continue using XAML

makotech221• 2 months ago

Winforms, wpf, blazor, maui, avalonia, what are you talking about

jdw642• 2 months ago

Alright. I'm actually fine with WinForms and WPF since my factory floor codes depend on them. But the reality is they aren't expressive enough for modern UIs. XAML is an issue, and WPF is boilerplate hell. But then Blazor is too heavy, MAUI is broken and buggy, Avalonia is underwhelming, and WinUI 3 is an absolute nightmare.

Salgat3• 2 months ago

What I don't get is why Java doesn't get dogged for desktop UI like C# does.

ethin• 2 months ago

Eto.forms too...

mynameisash• 2 months ago

C# used to be my favorite language, but having spent a lot of time in Rust using its algebraic data types + match statements + Option & Result types, then returning to C# to build a few moderately involved libraries, I'm horrified by the enums and null & error handling that I used to deal with all the time.

I knew that enums were really just named integer values and nothing more, but I had forgotten than you can build a perfectly legal enum from an integer out of the bounds of the enum's range. And a switch statement is non-exhaustive. (As I said, it had been a while since I used C# extensively.) What would have been a few lines of code in Rust turned into dozens to try to exhaustively protect against invalid input.

I know C# is a mature language that has been around for decades, but how janky everything feels comparatively really shocked me. I only very briefly played with F# about a decade ago, but my guess is that I could try to pick that up and call F# from C#, getting much better ergonomics with a combination of the two.

electroly• 2 months ago

I had forgotten than you can build a perfectly legal enum from an integer out of the bounds of the enum's range. And a switch statement is non-exhaustive

These are solved by the new feature described in the article that we're commenting on right now. They're giving us unions and exhaustive switch. Ctrl+F "canonical way to work with unions" in the article to see an example. One of the best parts about C# is they never stop bringing useful features from other languages back home to us in C#. It makes for a large language with a lot of features, but if we really want something, we'll eventually get it in C#.

at_compile_time• 2 months ago

Learning Rust really ruined C# for me. The explicitness saves you from so much defensive programming.

bob10293• 2 months ago

Winforms is better than ever. You can use it with .NET10 and WebView2 is a thing now.

sedatk4• 2 months ago

Responsive UI, fluent styling, are they straightforward now, or do you still need to jump hoops?

noveltyaccount• 2 months ago

Same. I wish there was a good story for .NET UI on desktop, mobile, and web. I find Maui Blazor Hybrid to be pretty close. The desktop and mobile variants compile to a webview bound to native code (no WASM, no JS), and the Web variant compiled to WASM. Much leaner than Electron. Pretty clunky though last time I tried though that was three years ago.

antonvs• 2 months ago

Did Anders Hejlsberg die, or something?

jafffsuds2• 2 months ago

He's been busy with the typescript-go project

SuperV1234• 2 months ago

Boxed, and needs complex incantations to avoid the boxing. Meh.

Metasyntactic5• 2 months ago

Hi there! One of the C# lang designers here. I discuss that here: https://news.ycombinator.com/item?id=48255658

Note that my expectation would be that the non-boxed form would be as trivial as adding `[NonBoxedUnion(SomeImplStrategyChoiceEnum)]` (or `[NonBoxedUnion]` for some default strategy choices that likely are ok).

This would give you extremely fine grained flexible choice on how you wanted your non-boxing union to work. There's no single right answer. There are just tradeoffs in terms of space/speed/copying-costs/memory-safety/etc.

I think it would make the most sense as people who care about boxing will have very different views and needs in terms of things like space, casting costs, copying speed etc.

The vast vast majority of users do not need to care at all. And for that, a boxed approach works exceptionally well.

sedatk4• 2 months ago

I've waited for union types on C# so long that I don't even care about syntax anymore. Just give us something that works. So, I appreciate the effort, I know it's taken at least a decade to get it into this shape, and much thought has gone into it. Kudos to the team.

LAC-Tech• 2 months ago

Wow 2016 would have loved this news.

cubefox7• 2 months ago

Most people don't know that there are fundamentally two different kinds of "union" types: "tagged unions" and "untagged unions". Now .NET is introducing tagged unions, but unfortunately they stick to the popular tradition of calling them just "unions", which greatly adds to the confusion.

To clarify, these tagged unions are fundamentally different from the untagged unions that can be found in languages like Typescript or Scala 3.

Tagged unions (also called "discriminated unions" or "sum types") are algebraic data types. They act as wrappers, via special constructors, for two (or more) disjoint types and values. So a tagged union acts like a bag that has two (or more) labelled ("tagged") slots, where each slot has exactly one type and exactly one of these slot can take a value.

Untagged unions are set theoretic (rather than algebraic) data types. They don't require wrapping via a special constructor. They behave like the logical OR. They are not disjoint slots of a separate construct. A variable or function x with the type "Foo | Bar" can be of type Foo, or Bar, or both. To access a Foo method on x, one has to first perform a typecheck for Foo, otherwise the compiler will refuse the method call (since x might only have the type Bar which would produce an exception). If a variable is of type A, it is also of type A|B ("A or B"). There are also intersection types (A&B) which indicate that something has both types rather than at least one, and complement/negation types (~A indicates that something is of any type except A). Though the latter are not implemented in any major language so far.

troad13• 2 months ago

Underlyingly, all unions are the same concept, exposed by C's `union` keyword, namely overlapping memory (as opposed to `struct`s, which are sequential memory). You can add a discriminator tag to your unions, your call. If it is impossible for there to be ambiguity (e.g. you track the state somewhere else, and you're dealing with a large array), it may be redundant / memory inefficient to tag every item.

Having these tags be a language construct is just a DX feature on top of unions. A very handy one, but it doesn't make tagged and untagged unions spring from different theoretical universes. I enjoy the ADT / set-theoretic debate as much as the next PL nerd, but theory ought to conform to reality, not vice versa.

cubefox7• 2 months ago

That's like saying Haskell is really an imperative language just because it's written in C. But it doesn't matter how it is implemented, it matters how it behaves on the surface.

jaen6• 2 months ago

These are not what are commonly called tagged unions. It's actually closer to an untagged union.

The C# union does not store any discriminator. Just look at the implementation - it's a single `object?` field.

The discriminative part is handled by run-time type information, which is stored in the object itself, not the union - which is why the C# built-in implementation requires boxing.

Also, you can use the same class/record type ("discriminator") in several different unions - again, a feature which ADTs/sum-types/tagged unions in most functional languages do not have.

You can even store one single object (ie. identical by reference equality) in several different union values at the same time, theoretically, which in combination with mutability is... uhh, certainly not common functional/mathematical semantics.

bartwe• 2 months ago

As a big user and fan of c# but this is a miss, as it always boxes value types.

Izikiel43• 2 months ago

There is the non boxing option, and this is the first iteration of the work, it's not one and done.

zamalek2• 2 months ago

When I cared about C# (which is no longer the case), I was lightly involved in the discussion for this and sibling features - mostly theorycrafting exactly your ask: the JIT team very succinctly expressed extreme disinterest in adding support of any kind.

The C# compiler could do it to a degree, but there would be too many caveats to make it actually useful. Unless the JIT team has a change of heart, you're probably never going to see this.

za3faran3• 2 months ago

What do you use these days language-wise?

hahn-kev3• 2 months ago

It always boxes them TODAY. Lately the team has been releasing an MVP and improving stuff (like perf) later on. I wouldn't be surprised if they do the same thing here, as noted in the article you can already work around that yourself.

algorithmsRcool• 2 months ago

But why not do it right the first time. This is an obvious performance pitfall for people that want to adopt this feature. It is bizarre to me after the last decade has been dedicated to performance improvments.

Metasyntactic5• 2 months ago

Hi there, one of the C# lang designers here. I discuss this a bit in https://news.ycombinator.com/item?id=48255658.

Contrary to what a lot of people guess, boxing is actually a really good strategy most of the time. And, is indeed what many people are doing here anyways. The design supports a pattern that allows for non-boxing, and I expect that we will both supply an implementation for that with reasonable defaults, and that source generators will be a great way to augment this to get highly specialized impl strategies for non-boxing depending on the varying domain needs any specialized customer may have.

viktorcode• 2 months ago

It is a downer, but I would like to test the performance first in the practical scenario. I've been working on a project where tagged unions would literally saved us from complexity. If that to happen again later I would go for boxed implementation and swallow up the penalty.

caioricciuti• 2 months ago

About time. TypeScript and Rust proved how much cleaner code gets when you can model "this OR that" at the type level. The real test will be whether library authors start using them in public APIs or if they stay a curiosity.

frutiger• 2 months ago

Standard ML proved this 50 years ago.

pdimitar• 2 months ago

If C# can get them then Golang can get them as well!

Come on Gophers! It's time.

LeonB• 2 months ago

Finally C# will have a more idiomatic way to represent this classic code example from “The Daily WTF” in 2005 —

    enum Bool 
    { 
        True, 
        False, 
        FileNotFound 
    };

See https://thedailywtf.com/articles/what_is_truth_0x3f_

mycall• 2 months ago

Could False = FileNotFound and this is a case of AST symbol constraints?

rich_sasha• 2 months ago

Awful as it is, I can easily imagine how it happened... Probably says more about me than the code.

tgv• 2 months ago

You're a true Romantic: Idealist and Pragmatist in one.

t-writescode• 2 months ago

What about Microsoft's own "MsoTrioState"? https://learn.microsoft.com/en-us/dotnet/api/microsoft.offic...

  enom MsoTrioState {
    Toggle,
    Mixed,
    True,
    False,
    CTrue
  };

8n4vidtmkvmk• 2 months ago

Is it called "trio" state because 3 of the 5 states are not supported?

I also like how True is -1. Beautiful all around!

drdaeman• 2 months ago

Usual reminder that one of the hardest problems in software engineering is still naming things ;-)

biglyburrito8• 2 months ago

More languages need to support enoms.

physicsguy• 2 months ago

About 12 years ago I went to go and work on some legacy C++ software when I was very green. We had a big code base and it had enum Bool { False = 0, True = 1 } everywhere. I thought it was a good idea to rationalise this since we had conversions all over the place to the modern bool type.

So I suggested it, got a PR up (bit painful) it got reviewed, went in, everything worked fine, and we came about a week towards releasing the product (6 monthly releases) before someone noticed that we couldn’t load files from previous versions. Turned out that we wrote lots of these old Bool types to binary data files and so the 4 byte data was now being read as 1 byte data. Oops. Reverted the whole lot. Lesson in humility!

warumdarum• 2 months ago

And as always when there is a mix of state and result, i post rop https://fsharpforfunandprofit.com/rop/

ComputerGuru• 2 months ago

Why would the default language-level union keyword implementation force boxing? Seems like a crazy decision if it could just also implement the HasValue/TryGet itself and avoid it?

Metasyntactic5• 2 months ago

Hi there! C# language designer here, and one of the people working on unions.

Boxing is not something inherently to be avoided. It actually can work better in many (most?) use cases, and avoids a lot of problems that non-boxing approaches often cause (like tearing and copy costs).

It's try that the non boxing pattern could be implemented by us. And it's very reasonable that that is something we may do post this release. However, it's a non-trivial area. There's no one correct 'non-boxed' implementation. For example, do you have separate fields for all your unmanaged data? or do you have a blob of bytes that is large enough to align all your unmanaged data from teh largest set of of unmanaged fields, and you unsafe index into that?

Similar question for managed data. Do you have strongly typed fields for that data? Or do you attempt to use objects, to compact to as little space as possible? The former avoids casting costs. The latter allows you to minimize space. You can also potentially use unsafe casts. But those might introduce memory holes in tearing situations. etc. etc.

Because of this, i think the best outcome is to define the pattern (which we've done) and then use generators to allow you to control precisely the impl strategy, giving you all the bells and knobs you want to best fit your domain.

ShalokShalom4• 2 months ago

Can we expect that the C# development team works with the F# crowd, to make this copied feature work on both?

pjmlp13• 2 months ago

It would help if generators usability and related docs would be improved, though.

They still feel like something only .NET team masters, and a few MVPs that wrote key reference blog posts about them.

msie• 2 months ago

Wow! I remember unions back in my Uni days. So many years ago.

Rapzid• 2 months ago

Shame it'll be like 3 years until System.Text.Json sees support for serialization or exporting schemas for them..

biglyburrito8• 2 months ago

Or being able to debug exceptions as easily as in Newtonsoft.Json.

spicyusername• 2 months ago

C# is such an underrated language.

A nice balance of language features and legibility.

merb• 2 months ago

sadly there is no ad hoc way of defining them. I do not care if they are boxed. I just want to say Success or Error1 or Error 2. Maybe I can live with or | or other stuff but not having ad hoc unions is basically not cool.

ShalokShalom4• 2 months ago

How about F# compatability?

.NET (OK, C#) finally gets union types

Related Stories