If C# can get them then Golang can get them as well!
Come on Gophers! It's time.
.NET (OK, C#) finally gets union types
131–140 of 300 posts
Re: .NET (OK, C#) finally gets union types
#132I 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.
Do you think by now C# has left Java behind in features and performance?
[deleted]
Re: .NET (OK, C#) finally gets union types
#133C# 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
Winforms, wpf, blazor, maui, avalonia, what are you talking about
Eto.forms too...
Re: .NET (OK, C#) finally gets union types
#134Most 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 Typescrip…
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…
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.
Re: .NET (OK, C#) finally gets union types
#135Earlier quoted context omitted.
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…
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.
> That's like saying Haskell is really an imperative language just because it's written in C
I honestly don't even remotely understand how you got to that from what I wrote.
Unions already have a definition. You cannot go around claiming that technically unions are not unions (and that "most people don't know" this), because theory X or Y overloads the term union to refer to some unrelated concept. That's fine and well and good, within that theory, but it does not displace the usual CS definition of union. It is a load-bearing definition.
A tagged union is so called because it is a union (overlapping memory) with a field (a tag) containing a discriminator (aka discriminated union). An untagged union is a union without this tag. These terms didn't come out of nowhere. They are transparent descriptors of what's happening.
It doesn't matter whether Haskell is implemented in C or Ruby, and it doesn't matter whether it's functional, object-oriented, or a DSL for modding Elden Ring, none of this changes what a union is. I'm very supportive of type theories exploring the option space for type constructs, but someone's going to have to implement these somehow. Such as with (tagged) unions. You know, that CS concept we have, with a settled and well understood meaning.
To be fair to you, I think you're letting a very narrow definition of 'union' shadow a much more usual and common definition of the word. And that's totally fine if that's the definition pertinent to you and your work, but if that's the case, maybe don't go around pontificating about how most people do not understand unions?
Re: .NET (OK, C#) finally gets union types
#136Earlier quoted context omitted.
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…
What do you use these days language-wise?
I'm part of The Rust Evangelism Strikeforce. In all seriousness, whatever suits the task well. Rust is for passion projects where I want to enjoy coding something; I find Go to be more of a direct competitor to C# - but it has the edge due to lacking exceptions (which is 15 years wasted of my life, never again). I'm always searching for something better, though.
Re: .NET (OK, C#) finally gets union types
#137Earlier quoted context omitted.
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.
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.
What new ideas did Zig bring to memory management?
Re: .NET (OK, C#) finally gets union types
#138F# leads the way and C# slowly catches up, as always. Yet for some reason, C# still gets all the mindshare.
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?
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.
Re: .NET (OK, C#) finally gets union types
#139Finally C# will have a more idiomatic way to represent this classic code example from “The Daily WTF” in 2005 —
enum Bool
{
True,
False,
FileNotFound
};
Re: .NET (OK, C#) finally gets union types
#140Earlier quoted context omitted.
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.
> That's like saying Haskell is really an imperative language just because it's written in C I honestly don't even remotely understand how you got to that from what I wrote. Unions already have a definition. You cannot go around claiming that technically unions are not unions (and that "most people don't know" this), because theory X or Y overloads the term union to refer to some unrelated concept. That's fine and we…
> You cannot go around claiming that 'technically' unions are not unions
I never said this. I said that there are two different kinds of unions with quite different definitions and behaviors.
> A tagged union is so called because it is a union (overlapping memory) with a field (a tag) containing a discriminator (aka discriminated union). An untagged union is a union without this tag.
That alone doesn't sufficiently describe the "unions" in set theoretic type systems like TypeScript. As I said, these unions are not disjoint and don't involve the special constructor that tagged unions/discriminated unions/sum types in algebraic type systems do. They also have logical implications like A implying A|B. Or A|A being equivalent to A, which isn't the case for discriminated/tagged unions. Maybe they are implemented similarly under the hood, but that doesn't negate the difference.
Edit: It's probably fair to say that "untagged unions" in languages like TypeScript, Ceylon or Scala 3 (set theoretic type systems) are different from "untagged unions" in C. It only adds to the confusion...