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

221–230 of 315 posts

Re: Official proposal for Type Unions in C#

#221

Post by cies »

jcparkyn wrote: post #216
zarathustreal wrote: post #156

Earlier quoted context omitted.

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”

But then what name would they use for tuples, which are distinct from records?

both tuples and record (structs) are product types. tuples are "untagged", records/structs are "tagged" (the members have names).

sum types also have tagged and untagged variants. the untagged variants are less useful (more cumbersome) in case of sum types and hence often are not implemented in languages.

Re: Official proposal for Type Unions in C#

#222

Post by neonsunset »

Buttons840 wrote: post #157
tester756 wrote: post #114

Earlier quoted context omitted.

I've been writing C, C++, C# and some js/sql/ts/python for money. Lua for lulz. And *nothing* gets even fucking close in terms of productivity to C#. Great language, mature and robust ecosystem with sane compilation times and great tooling: package manager, test runner, strong debugger, one CLI with almost all tools needed. I wish C++ was half as enjoyable as C# is.

I'm a Linux user who prefers open-source tools. I not a fan of Microsoft's programs, tools, editors, etc. What would you suggest I do to be productive with C#?

If your goal is to avoid anything touched by msft employees, then the answer is you can't use C#. Just like you can't use Java if you want to avoid Oracle because of their predatory practices, or can't use Swift if you want to avoid Apple, or can't use Go if you want to avoid the AdTech company. In fact, just limiting to MS you probably can't use Java or C/C++ either as they have contributions to compilers for both.

But this is rather silly, so I'm going to assume the question is more reasonable "What can I do as a Linux user to have positive experience with C#?".

In this case, the response is very simple - you just install the SDK (sudo apt/dnf install dotnet-sdk-8.0) and then pick either VS Code and base (and free and MIT) C# extension (you do not need DevKit) or combine csharp-ls and Neovim. Other text editors that support LSP will also work. Nothing else is required.

Rider is suggested but it is absolutely optional, especially if you are not looking for that kind of high-tier IDE and prefer simpler (and faster) text editing experience.

Re: Official proposal for Type Unions in C#

#223

Post by neonsunset »

codr7 wrote: post #217
kkukshtel wrote: post #194

Really excited for this proposal as it's been the main thing I have to apoligize for when extolling the values of C#. Outside of this it's hard to think of other major features C# lacks for a language. Additionally, excited to now watch this go in and people on HN still act like C# is the same it was 10 years ago.

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 have time, please look at sharpl PR which simplifies the implementation and makes it more compiler-friendly: https://github.com/codr7/sharpl/pull/2

In any case, welcome to C# and thanks!

Re: Official proposal for Type Unions in C#

#224

Post by LAC-Tech »

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

Earlier quoted context omitted.

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.

https://en.wikipedia.org/wiki/Multiple_inheritance#Mitigatio...

CLOS and Ocaml figured it out

Re: Official proposal for Type Unions in C#

#226

Post by neonsunset »

andygocke wrote: post #203
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…

Will there be any layout optimizations performed by Roslyn for fields that can be aliased? E.g.: for a type union which has variants with 2 object fields and one ushort-sized at most each, have a base layout of (object, object, short)?

Re: Official proposal for Type Unions in C#

#227

Post by nsonha »

tester756 wrote: post #127
LAC-Tech wrote: post #98

I always think it's a shame that instead of C# becoming a better OO language, they keep trying to become an uglier F#. IE, why is the syntax for multiple dispatch still so clunky? I know I know, pseudo OO took over the world, and then people revolted against it, so the easiest thing to do to stay relevant is to become "slightly functional with curly braces", rather than to actually try and do OO well.

What does "better OO" mean here? Which concepts or feature you have on mind?

multiple dispatch or whatever helps people stop thinking about a hierarchy of inheritance and more in terms of objects and messages.

Re: Official proposal for Type Unions in C#

#228

Post by mastry »

hakanderyal wrote: post #215
lyu07282 wrote: post #205

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.

Mixins via inheritance is a sweet pattern that I miss in C# sometimes.

C# has default interface implementations now, that can be used to create mixins...

https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...

Re: Official proposal for Type Unions in C#

#229

Post by hakanderyal »

mastry wrote: post #228
hakanderyal wrote: post #215

Earlier quoted context omitted.

Mixins via inheritance is a sweet pattern that I miss in C# sometimes.

C# has default interface implementations now, that can be used to create mixins... https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...

Yeah I sometimes use them but they don’t cover all the cases. I’m waiting for roles/extensions to see if I can achieve a similar result.

https://github.com/dotnet/csharplang/discussions/5496

Re: Official proposal for Type Unions in C#

#230

Post by freilanzer »

electroly wrote: post #31
Eji1700 wrote: post #4

Earlier quoted context omitted.

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'm glad they're simply turning C# into F#. They're coming to us where we are, rather than forcing us to make a jump. I'm a relatively "blue collar" developer, I know a little about FP (not enough to be productive in F#) but I have tons of C# experience. I appreciate them taking the good stuff from F# and making it understandable to C# developers. It's been a delightful progression; no big jumps, no paradigm shifts,…

> I'm glad they're simply turning C# into F#.

I'm not. I find F#s syntax much more pleasing and elegant, and I'm afraid F# will wither away when C# is a watered down version of it.

Post reply on HN