Live data from Hacker News

Official proposal for Type Unions in C#

github.com

231–240 of 315 posts

Re: Official proposal for Type Unions in C#

#231
post #96

Earlier quoted context omitted.

"Tagged" sounds like an implementation detail to me (that it has a "tag" internally to tell between types). I suspect they added "type" to "union" to make it clear what is about (about types). The syntax itself has just "union", judging by the document. UPD. They have this in the FAQ: Q: Why are there no tagged unions? A: Union structs are both tagged unions and type unions. Under the hood, a union struct is a tagged…

I don't think tag is an implementation detail generally, for example: enum Option { None, Some(T), } The tags are "None" and "Some" which are definitely user facing. But I see what they mean a bit with the C# example: union U { A(int x, string y); B(int z); C; } So it seems like "A", "B", and "C" are tags but also their own distinct types, with a implicit conversions between those and the overall union type

Tagged unions are an implementation detail and are often not the optimal way to solve this problem.

Take Option, it's a ZST, not only is there no "tag" there isn't any data at all. In type theory this is fine, we added an empty type to the unit type, we got a unit type.

Re: Official proposal for Type Unions in C#

#233

Earlier quoted context omitted.

> I don't think "type union" is a term of the art "sum type" is the term of art in Computer Science theory, but "union type" is also used. See https://en.wikipedia.org/wiki/Type_theory#Sum_type https://en.wikipedia.org/wiki/Tagged_union

At this point, calling it by its correct name (Sum Types) would leave them looking stupid for not using the correct name (Product Types) for their “records”

That construct has been called a “record” since, I believe, 1970 in Pascal.

Re: Official proposal for Type Unions in C#

#235

Earlier quoted context omitted.

I think they solved the problem by not supporting multiple inheritance, instead supporting interfaces and/or traits. But also "composition over inheritance" pretty much won, thankfully imho.

https://en.wikipedia.org/wiki/Multiple_inheritance#Mitigatio... CLOS and Ocaml figured it out

When in doubt look to CLOS.

Re: Official proposal for Type Unions in C#

#236
post #217

Earlier quoted context omitted.

Proper type aliases would be nice, but I have to say I really enjoy coding C# these days.

Why hello again :) I really appreciate your projects and noticed the web server one. There's an ask - please prefer built-in containers unless you have to use custom ones, at least for now. It is also not necessary to define aliases for types accessible directly: `using Namespace.AnotherNamespace` is enough to access them. There is no need to re-define the alias for `AnotherNamespace` if it matches either. When you h…

Hello there :)

Just a little bit of patience with the collections, I'm slowly learning to trust the native offerings, at least there's a regular List at the bottom now, much thanks to you.

I'm just used to using more descriptive type names, that's all. It bothers me to no end when I have to keep guessing and memorizing the correct primitive type for a concept. Also makes the code more difficult to read.

I'll have a look at the PR, thank you!

Re: Official proposal for Type Unions in C#

#237
post #3

Huh, 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…

As of 2020 (when I stopped using F# and .Net in general), the CLR only had inheritance and F#'s enums were actually implemented using inheritance. Eg Some and None were derived classes of Option class. You would see it if you inspected an F# assembly in a decompiler. I don't know if it's still the same today. This C# proposal has anonymous enums using `A or B` syntax which would be hard to make work as sugar over inh…

This is only partially true. Both Some and None were always instances of single FSharpOption class (None is actually not an instance, but null), however custom DUs are indeed compiled into classes with inheritance

Re: Official proposal for Type Unions in C#

#239
post #206

As a long time C# dev, I feel like I’m missing something about this proposal. The use case for this doesn’t seem well defined to me. Could someone give me a real world example? I’m pretty sure you can implement the example in this proposal by declaring an empty interface and having some record classes that “implement” it. Does that lose something that I’m not seeing?

Like an enum, a union have a closed set of elements so it can be statically checked all cases are handled.

With an interface, someone could add a new implementation, causing codee to fail at runtime.

Re: Official proposal for Type Unions in C#

#240

Earlier quoted context omitted.

This comment feels like it's been written 20 years ago. C# runs natively anywhere and this has been true for at least a decade.

I'd like a supported port of .NET to the BSDs.

There is one: https://www.freshports.org/lang/dotnet

    pkg install lang/dotnet
Note that not everything will work, and it is community-supported. But the effort is there, and there are contributions to dotnet/runtime from time to time to further improve or fix it. It's in a better state than it was 2 years ago.
Post reply on HN