Comment by bob1029 3 days ago
You can write a vast majority of your C# codebase in a functional style if you prefer to.
All the good stuff has been pirated from F# land by now: First-class functions, pattern matching, expression-bodied members, async functional composition, records, immutable collections, optional types, etc.
It has been in discussion for quite some time. I believe they'll get there soon: (example) https://dev.to/canro91/it-seems-the-c-team-is-finally-consid...
In the interim, MS demonstrates how C# 8.0+ can fake it pretty well with recursive pattern matching: https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
Not the same I know, and I would love me a true ADT in C#.
Edit (a formal proposal): https://github.com/dotnet/csharplang/blob/18a527bcc1f0bdaf54...
There's also going to be quite a big ecosystem / standard library difference between languages that had fundamental type system features since the beginning vs. languages that added fundamental features 23 years later.
Imagine all the functions that might return one thing or another, which was inexpressible in C# (until this proposal is shipped), will all these functions release new versions to express what they couldn't express before? Will there be an ecosystem split between static typing and dynamic typing?
Having reviewed the proposal (of course no guarantee that's what discriminated unions (aka product types aka algebraic data types) will look like), and it appears that it very much integrates nicely with the language.
I don't suspect they'll make too many changes (if any) to the existing standard library itself, but rather will put functions into their own sub-namespace moving forward like they did with concurrent containers and the like.
Given their penchant for backwards compatibility, I think old code is safe. Will it create a schism? In some codebases, sure. Folks always want to eat the freshest meat. But if they do it in a non-obtrusive way, it could integrate nicely. It reminds me of tuples, which had a similar expansion of capabilities, but the integration went pretty well.
While we wait for the official discriminated union feature, the OneOf package is a pretty good stand-in: https://github.com/mcintyre321/OneOf
My 2p's worth is that the whole of F# is more than the some of its parts. When you say in your previous comment "All the good stuff has been pirated from F#" it misses the point of what it's actually like to use F#. The problem is, it's almost impossible to communicate what it's like. You have to try it and you have to keep going until you get over the initial "WTF!?" hump. There will be a WTF hump.
For example, C# may have cribbed the language features, but F# is expression based and immutable by default. Try using the same features in this context and the whole game changes.
I don't know if there's a name for it but essentially F# is where the language designers can push the boundaries and try extremely new things that 99% of users will not want or need, but eventually some of them are such good ideas that they feed back into C#.
Maybe that's just research, and I'm glad that Microsoft hasn't killed F# (I do work there, but I don't write F# at work.)
> F# is where the language designers can push the boundaries
It really isn't, not anymore. F# now evolves conservatively, just trying to remove warts and keep up with C# interop.
And even then some C# features were considered too complex/powerful to implement (e.g. variance, scoped refs) or implemented in weaker, incompatible ways when C#'s design is considered messy (e.g. F#'s non-nullable constraints disallow value-types, which breaks for some generic methods written in C#, sadly even part of the System libs).
I wouldn't say "all" - C# doesn't have discriminated unions yet, which is kind of a big one, especially when you're also looking at pattern matching. A