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

201–210 of 315 posts

Re: Official proposal for Type Unions in C#

#201

Post by tubthumper8 »

JoshTriplett wrote: post #55
paulddraper wrote: post #51

Earlier quoted context omitted.

> 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.

How widely understood and appreciated were algebraic data types at the time Cfront was first floated as the precursor to C++? To what degree had they shown up in mainstream languages?

Cfront being around 1983 would mean at least ALGOL68 and Pascal would've been well-known at the time. Ada is cited as an influence on C++. ML languages were definitely not mainstream but if Wikipedia is to be believed, ML was an influence on C++ as well.

The idea would've been well understood, but if the goal of C++ was "C with classes" or more accurately "C + Simula" then it just wasn't part of the goal. And of course we got 20 years of essentially forgetting that sum types existed outside of ML languages until they were "rediscovered"

Re: Official proposal for Type Unions in C#

#203

Post by andygocke »

facturi wrote: post #179

That proposal doesn't mention how the union struct handles tearing under concurrent modification. Tearing can cause memory safety issue. Variant A can have an integer field and variant B can have a reference field in the same offset. Tearing can cause it to treat an integer as reference.

I’m the author of the original issue — I agree, we’ll have to ensure the struct layout is solved. I think the only thing that makes sense is to just waste a little space and store the fields side-by-side. In almost all cases where people would use a struct I think this is an acceptable tradeoff.

At the point where you have more than 5 cases, the GC overhead starts to get shrink in comparison to the calling convention and copying overhead anyway.

Re: Official proposal for Type Unions in C#

#204

Post by jmaker »

tombert wrote: post #14
kriiuuu wrote: post #11

Earlier quoted context omitted.

I feel the same about Scala. I use Scala3 daily and almost every other language is such a step back. I have looked at F# and it looks like one of the only other languages I would enjoy as much as Scala. Haskell is nice too, but the ecosystem is just not quite there. F# being able to tap into the rich C# ecosystem and Scala being able to tap into the Java ecosystem is such a win and makes them feel a lot less niche wh…

I do like Scala, and I haven't touched Scala3, but I've found it pretty unwieldy for actual use. It feels like I'm constantly fighting with the type system in a way that ends up being annoying an unpleasant. To be clear, it's not like I'm new to functional languages and their type systems, I've been doing Haskell for forever, and I did F# for a multiple years, but Scala has never really clicked for me. Personally, fo…

My experience is diagonally opposite. I haven’t written Scala for a while now, I guess a year or two by now, and just a few days ago got back to it because the logic I wanted to express was hard to fit in to Java, Kotlin, C#, Go. I have certain performance and correctness requirements and most stuff is JVM based. So I thought like okay, I can isolate it in a service and invoke from another JVM, but let me just try to express my type families and the algos the easy way around, and whoosh I see Scala compile and give me the correct results on my first attempt.

That was a bit of a surprise - I’d forgotten how expressive Scala is. I didn’t need any “advanced” type system features. But my time to market was literally a couple hours instead of days like with C#, Java, Kotlin, Go, bending to fit the logic into the confines of their type systems. Kotlin is just awesome and very expressive. But it turns out, to me, Scala is somehow very natural - just write what you think, and it works.

Interestingly, that was also my experience many years ago when I first exposed myself to Scala in a numerical analysis class just to avoid Java, and it just worked right away. I recall well that surprised feeling. So I’m kinda happy to move back to Scala now. But I’ll also try to implement the same in F#, right after delivering the next feature set.

Re: Official proposal for Type Unions in C#

#205

Post by lyu07282 »

LAC-Tech wrote: post #136
lyu07282 wrote: post #120

Earlier quoted context omitted.

> What would it take for C# and/or others to "do OO well"? Multiple inheritance. (j/k)

Unironically this. Having "interfaces" and "abstract classes" is just a kludge, multiple inheritance covers all of this with one language construct. The "diamond problem" is a C++ issue, every other language solved it.

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.

Re: Official proposal for Type Unions in C#

#206

Post by arnath »

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?

Re: Official proposal for Type Unions in C#

#207

Post by celdon25 »

lmm wrote: post #196
celdon25 wrote: post #170

Earlier quoted context omitted.

No linters in C#? That’s a good one. C# as a language has always been cross-platform. Though the last few versions have made incredible gains in performance optimizations. You won’t get the flexibility of C++ but the performance comes close to it in most cases, when written optimally. And you don’t have to deal with arcane, bullshit build systems with a learning curve that is worse than the language, and breaks down…

> C# as a language has always been cross-platform. Not really. Like, it notionally ran on FreeBSD, but nontrivial programs never actually worked until recently, and even now they mostly still don't.

The lack of an available runtime implementation, or the transitive dependencies of the dynamically linked reference assemblies, does not preclude the compiled assembly from being cross-platform. The assembly within the file built by a C# compiler contains IL code that can be extracted by cross-platform tooling. There’s nothing OS-specific at that layer.

We are talking about the language, not the runtime implementation.

Re: Official proposal for Type Unions in C#

#208

Post by pipes »

progmetaldev wrote: post #130
pipes wrote: post #125

Earlier quoted context omitted.

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…

Thanks :)

Re: Official proposal for Type Unions in C#

#209

Post by alkonaut »

arnath wrote: 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?

That type of hierarchy is “open” in the sense that when you handle them you can’t know whether you handled all of them. Anyone can make a new implementation of your interface, potentially in code that isn’t yours.

Also, the options may not share any surface area at all, so the “interface” for all the types may be empty which is a bit unnatural in OO.

But under the hood, it’s just this: a type hierarchy. But the hierarchy is closed for extension, and (this is the key part you’d not get if doing this “manually” as you describe) when code uses the cases, failing to account for a case will cause an error at compile time.

Re: Official proposal for Type Unions in C#

#210

Post by larusso »

arnath wrote: 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?

I think the most down to earth example is the AST or data protocol examples. Take Jason for example. Instead of having a JsonValue class to hold the data you would have a Union type that is either string, bool, number, array of your union type or map type which uses a string as key and the same union type as value. It would also allow to implement result types like rust has them. So you could define an API that returns a value or an error. I didn’t see in the proposal if they talked about generics though. In functional programming world this is mainly known as algebraic data types. I can say that if you get used to model types like this you really start to miss it in languages that don’t support it.

[1] https://en.m.wikipedia.org/wiki/Algebraic_data_type

Post reply on HN