Official proposal for Type Unions in C#
github.com
Official proposal for Type Unions in C#
1–10 of 315 posts
Re: Official proposal for Type Unions in C#
#2> The interior layout of the union struct is chosen to allow for efficient storage of the data found within the different possible member types with tradeoffs between speed and size chosen by the compiler.
Having _attempted_ (and being bitten by) far too much black magic with C# unions in the past (using FieldOffset), there is an unfortunate situation here: aliasing a pointer/ref value and value is UB. This means that a struct union of a u64 and an object would need separate fields for each, wasting 8 bytes. That is, unless the ryujit/gc is updated with knowledge about this.
Re: Official proposal for Type Unions in C#
#3Huh, I did F# for years with discriminated unions, and I guess I just assumed C# would have had them by now.
I know not everyone likes them, but for typed languages I find it extremely hard to go back to languages without ADTs of some kind. I do Java for my current job, and Java is generally fine enough, but it's a little annoying when I have to do whacky workarounds with wrapper classes to get something that would be done in three lines of F#.
Re: Official proposal for Type Unions in C#
#4Huh, I did F# for years with discriminated unions, and I guess I just assumed C# would have had them by now. I know not everyone likes them, but for typed languages I find it extremely hard to go back to languages without ADTs of some kind. I do Java for my current job, and Java is generally fine enough, but it's a little annoying when I have to do whacky workarounds with wrapper classes to get something that would b…
F# is so hard to walk back from. I wish Microsoft would support it better and actually push it, because it's such a perfect sweet spot. Most of the functional advantages without being shackled to pure functions and the like is so easy to develop in.
Instead they've been, very slowly, turning C# into F#, which is even weirder to watch.
Re: Official proposal for Type Unions in C#
#5Huh, I did F# for years with discriminated unions, and I guess I just assumed C# would have had them by now. I know not everyone likes them, but for typed languages I find it extremely hard to go back to languages without ADTs of some kind. I do Java for my current job, and Java is generally fine enough, but it's a little annoying when I have to do whacky workarounds with wrapper classes to get something that would b…
F# is so hard to walk back from. I wish Microsoft would support it better and actually push it, because it's such a perfect sweet spot. Most of the functional advantages without being shackled to pure functions and the like is so easy to develop in. Instead they've been, very slowly, turning C# into F#, which is even weirder to watch.
It makes sense from a language adoption standpoint, especially if you look at typescript for example, which is also by Microsoft. Though I agree with you personally
Re: Official proposal for Type Unions in C#
#6I’ve lost track of all of the red/blue/white/black pill color metaphors, but unions with exhaustive pattern matching is one of the toughest of all programming language features to live without once you become aware of it.
I’ve never felt like I’ve fully understood the implications of the expression problem https://en.wikipedia.org/wiki/Expression_problem but my best/latest personal hypothesis is that providing extension points via conventional polymorphism might be best suited for unknown/future clients who might extend the code, but unions with exhaustive pattern matching seem better suited for code that I or my team owns. I don’t typically want to extend that code. More often, I instead want to update my core data structures to reflect ongoing changes in my understanding of the business domain, more often than not using these Union-type relationships, and then lean on the compiler errors maximally to get feedback about where the rest of the imperative code now no longer matches the business domain data structures.
Re: Official proposal for Type Unions in C#
#7Huh, I did F# for years with discriminated unions, and I guess I just assumed C# would have had them by now. I know not everyone likes them, but for typed languages I find it extremely hard to go back to languages without ADTs of some kind. I do Java for my current job, and Java is generally fine enough, but it's a little annoying when I have to do whacky workarounds with wrapper classes to get something that would b…
Good news is that you can achieve this with relatively little boilerplate in Java with sealed interfaces and records now. Relative to Java that is
Re: Official proposal for Type Unions in C#
#8Every 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 rust with discriminated unions being the biggest reason. It's incredibly hard to go back to a language without even basic ADTs after seeing the light.
Re: Official proposal for Type Unions in C#
#9Huh, I did F# for years with discriminated unions, and I guess I just assumed C# would have had them by now. I know not everyone likes them, but for typed languages I find it extremely hard to go back to languages without ADTs of some kind. I do Java for my current job, and Java is generally fine enough, but it's a little annoying when I have to do whacky workarounds with wrapper classes to get something that would b…
F# is so hard to walk back from. I wish Microsoft would support it better and actually push it, because it's such a perfect sweet spot. Most of the functional advantages without being shackled to pure functions and the like is so easy to develop in. Instead they've been, very slowly, turning C# into F#, which is even weirder to watch.
I agree; F# is probably my favorite of the "compromise" functional languages [1], where you can drop into the "wrong" way when necessary. F# pushes a more or less pure approach, but in some cases, like when mutation will be a bit easier and/or faster, it's easy to do that as well. I also think that even F#'s OOP is actually really pleasant...If nothing else, it's a lot more terse than C#'s.
I miss writing it; I haven't had a job using it in a few years but I really enjoyed writing code in it when I did. Most of my personal projects haven't really been able to use .NET for awhile, so I never seem to have an excuse to play with F# in my personal time.
I never got into C#, so I can't say that I really feel the pain of the C# transition into F#.
[1] At least in the typed world. I'm also really partial to Clojure.
Re: Official proposal for Type Unions in C#
#10Huh, I did F# for years with discriminated unions, and I guess I just assumed C# would have had them by now. I know not everyone likes them, but for typed languages I find it extremely hard to go back to languages without ADTs of some kind. I do Java for my current job, and Java is generally fine enough, but it's a little annoying when I have to do whacky workarounds with wrapper classes to get something that would b…
Good news is that you can achieve this with relatively little boilerplate in Java with sealed interfaces and records now. Relative to Java that is
Yeah, I know, and I have started using those, though that doesn't undo the last 15 years of Java code that I've written where that wasn't really an option.
Still, good to see Java joining the 21st century at least.