5 ms·

Microsoft has a good tutorial that showcases what you can do when designing with switch expressions in mind: https://learn.microsoft.com/en-us/dotnet/csharp/fu

by jcpst 3y ago

Microsoft has a good tutorial that showcases what you can do when designing with switch expressions in mind: https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/tutorials/pattern-matching https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals... Probably one of my favorite recent-ish additions to the language.

rjbwork 3y ago
The fact that they've added all of this great stuff and have STILL not added real discriminated unions is a damn travesty. It would just so drastically improve the language.
- isanjay 3y ago
  Would love to see DU in C# I think they would add it by C# 14 or 15.
- pjmlp 3y ago
  Maybe the rest of the .NET world has more important stuff to care about? Anyone that cares so deeply about them can do the work on a F# assembly.
  - Risord 3y ago
    Yea I don’t care neither but business seems to care. If you listen closely their specs are pretty much bloated with DUs.
  - diarrhea 3y ago
    I’m not arguing there is more important stuff, but DUs would enhance the language on a wide, fundamental level, accelerating a lot of other advancements.
    - pjmlp 3y ago
      I have used Caml Light, Standard ML, Objective Caml, Haskell, and fail to see the greatness of such advancements. C# has done great in the industry for the past 23 years without them.
      - pharmakom 3y ago
        This is a really interesting comment. Do you not miss the features and expressivity of those languages?
        pjmlp 3y ago
        The only thing I really missed, has been adopted during the latest years, pattern matching. Languages are not used in isolation, great IDE experience, and having mature libraries for every use I can think of, is more valuable than grammar and semantics. Also a reason why I would rather do FP in C++23 than Haskell, even with all the warts and paper cuts it entails, ecosystem.
        pharmakom 3y ago
        Wouldn't F# or Scala hit these ecosystem needs whilst also delivering pattern matching (done well), sum types, etc?
        pjmlp 3y ago
        If only the tooling was at the same level as C# and Java. Additionally, they add friction to a development stack, now everyone needs to be confortable with two language stacks, and most of the time it isn't really worth it.
  - keithnz 3y ago
    its because they are easy to do in C# without explicit support, but the proposal is still in the works, but they argue a lot about the syntax and about exhaustive type checking for all the edge cases.
  - Turskarama 3y ago
    One of the problems here is that C# and F# interop isn't always as easy as the article implies. F# has a lot of types which, when exposed in a public API, are ugly as sin in other .NET languages.
    - DaiPlusPlus 3y ago
      That issue is not F# or C#'s fault - it's a limitation of the expressiveness of the CLR's type-system (it doesn't support higher-kinded types, varadic type parameterization, or non-typename type parameters). The hope and the expectation is that the CLR will gain support for first-class representations of F# concepts to allow for greater interop with C# scenarios, but the CLR's development has always been tied to C#, with other CLR languages like VB.NET and C++/CLI only exerting minor influence on the CLR's design with most of their language-specific idiosyncrasies being handled by library-code and compile-time tricks instead (e.g. VB.NET's "On Error Resume Next" statement is implemented by having the compiler wrap each individual statement in a try/catch instead of having the CLR specifically support it (though in this specific case that's probably a good idea as OnErrorResumeNext is a horrible idea I'm sure we all agree).
      - pjmlp 3y ago
        Minor correction, only Managed C++ and C++/CLI have the full power of the CLI, many of the performance improvements in C# have been related to exposing those MSIL capabilities to C# as well, which before required generating bytecode directly. Which is kind of ironic given how they usually leave C++/CLI out of the picture, including the cross platform story.
  - tokinonagare 3y ago
    Did you check the recents blog posts about C#12? Clearly the team has ran out of ideas for meaningful improvements to the language, while ignoring discriminated unions which is the most important concept missing in the language. [1] https://devblogs.microsoft.com/dotnet/new-csharp-12-preview-features/ https://devblogs.microsoft.com/dotnet/new-csharp-12-preview-... [2] https://devblogs.microsoft.com/dotnet/new-csharp-12-preview-features/ https://devblogs.microsoft.com/dotnet/new-csharp-12-preview-...
    - pjmlp 3y ago
      Yes, I am not a fan of inline arrays syntax, or interceptors. I can manage without DU, have used plenty of languages without them since Caml Light.
- jjtheblunt 3y ago
  genuine misunderstanding : what do you mean by "real" discriminated unions. I believe I am overlooking something (probably obvious even to me) since i know: https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/discriminated-unions https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... is perhaps a misuse of the term in this context. (I'm guessing you mean more like in Rust, but am not sure.)
  - Smaug123 3y ago
    The parent comment means that C# lacks DUs, not that F# lacks them.
    - jjtheblunt 3y ago
      Oh thank you
- WorldMaker 3y ago
  Given few people anticipated ValueTuple and C# adding a more direct tuple syntax, I feel like it is only a matter of time before C# adds discriminated unions. (There are multiple proposals tracking the idea. This seems the most comprehensive and "central": https://github.com/dotnet/csharplang/issues/7016 https://github.com/dotnet/csharplang/issues/7016)
  - chem83 3y ago
    This seem to be a longer running one: https://github.com/dotnet/csharplang/issues/113 https://github.com/dotnet/csharplang/issues/113
- keithnz 3y ago
  you can easily do them, I added a comment on the article showing how.... https://github.com/linkdotnet/Blog.Discussions/discussions/73#discussioncomment-6663149 https://github.com/linkdotnet/Blog.Discussions/discussions/7...
  - LelouBil 3y ago
    It's just like in Kotlin !
  - Turskarama 3y ago
    It's missing the killer feature though, which is the compiler warning you when you haven't done an exhaustive match. That is the magic which makes adding new values easy instead of hunting through code to find if you missed the new case anywhere.
    - mycall 3y ago
      I've only needed discriminated unions inside C# when I'm using pinvoke to C DLLs. I would think Rosylin supports some compiler warning for them, but I haven't checked that.
    - keithnz 3y ago
      I used to think that.... but actually, in practice, and I've been using them for a long time now, it doesn't make much difference, good tooling will generate the cases and help you find all instances pretty quick (I use Rider).
  - Rapzid 3y ago
    My guess is roles will land first in C#13. Is is kind of a pain particularly when working across Typescript projects. OneOf is cool, but it DOES NOT work well with null and thus optional parameters.
  - rjbwork 3y ago
    This is the kind of OG way to do it even before we had patterns. There are a couple of problems with it, least of which is that I can't then use one or both of those in a wider union elsewhere, because their definitions are bound to that parent class. Ideally I'd like to see something very similar to the linked OneOf library. That allows you to do both in-line definitions OR subclass from OneOf<T1,T2,T3...> to reify the union as a class as well. If that is done and integrated properly into the pattern matching system, I believe it will yield very powerful expressiveness.
- ftcHn 3y ago
  Agree. For now, you can get a reasonable DU via an [external library](https://github.com/mcintyre321/OneOf https://github.com/mcintyre321/OneOf). [Nick Chapsas Video on Usage](https://www.youtube.com/watch?v=7z-xjijYfcI https://www.youtube.com/watch?v=7z-xjijYfcI).

by jcpst 3y ago

rjbwork 3y ago

The fact that they've added all of this great stuff and have STILL not added real discriminated unions is a damn travesty. It would just so drastically improve the language.

isanjay 3y ago
Would love to see DU in C# I think they would add it by C# 14 or 15.
pjmlp 3y ago
Maybe the rest of the .NET world has more important stuff to care about? Anyone that cares so deeply about them can do the work on a F# assembly.
- Risord 3y ago
  Yea I don’t care neither but business seems to care. If you listen closely their specs are pretty much bloated with DUs.
- diarrhea 3y ago
  I’m not arguing there is more important stuff, but DUs would enhance the language on a wide, fundamental level, accelerating a lot of other advancements.
  - pjmlp 3y ago
    I have used Caml Light, Standard ML, Objective Caml, Haskell, and fail to see the greatness of such advancements. C# has done great in the industry for the past 23 years without them.
    - pharmakom 3y ago
      This is a really interesting comment. Do you not miss the features and expressivity of those languages?
      - pjmlp 3y ago
        The only thing I really missed, has been adopted during the latest years, pattern matching. Languages are not used in isolation, great IDE experience, and having mature libraries for every use I can think of, is more valuable than grammar and semantics. Also a reason why I would rather do FP in C++23 than Haskell, even with all the warts and paper cuts it entails, ecosystem.
        pharmakom 3y ago
        Wouldn't F# or Scala hit these ecosystem needs whilst also delivering pattern matching (done well), sum types, etc?
        pjmlp 3y ago
        If only the tooling was at the same level as C# and Java. Additionally, they add friction to a development stack, now everyone needs to be confortable with two language stacks, and most of the time it isn't really worth it.
- keithnz 3y ago
  its because they are easy to do in C# without explicit support, but the proposal is still in the works, but they argue a lot about the syntax and about exhaustive type checking for all the edge cases.
- Turskarama 3y ago
  One of the problems here is that C# and F# interop isn't always as easy as the article implies. F# has a lot of types which, when exposed in a public API, are ugly as sin in other .NET languages.
  - DaiPlusPlus 3y ago
    That issue is not F# or C#'s fault - it's a limitation of the expressiveness of the CLR's type-system (it doesn't support higher-kinded types, varadic type parameterization, or non-typename type parameters). The hope and the expectation is that the CLR will gain support for first-class representations of F# concepts to allow for greater interop with C# scenarios, but the CLR's development has always been tied to C#, with other CLR languages like VB.NET and C++/CLI only exerting minor influence on the CLR's design with most of their language-specific idiosyncrasies being handled by library-code and compile-time tricks instead (e.g. VB.NET's "On Error Resume Next" statement is implemented by having the compiler wrap each individual statement in a try/catch instead of having the CLR specifically support it (though in this specific case that's probably a good idea as OnErrorResumeNext is a horrible idea I'm sure we all agree).
    - pjmlp 3y ago
      Minor correction, only Managed C++ and C++/CLI have the full power of the CLI, many of the performance improvements in C# have been related to exposing those MSIL capabilities to C# as well, which before required generating bytecode directly. Which is kind of ironic given how they usually leave C++/CLI out of the picture, including the cross platform story.
- tokinonagare 3y ago
  Did you check the recents blog posts about C#12? Clearly the team has ran out of ideas for meaningful improvements to the language, while ignoring discriminated unions which is the most important concept missing in the language. [1] https://devblogs.microsoft.com/dotnet/new-csharp-12-preview-features/ https://devblogs.microsoft.com/dotnet/new-csharp-12-preview-... [2] https://devblogs.microsoft.com/dotnet/new-csharp-12-preview-features/ https://devblogs.microsoft.com/dotnet/new-csharp-12-preview-...
  - pjmlp 3y ago
    Yes, I am not a fan of inline arrays syntax, or interceptors. I can manage without DU, have used plenty of languages without them since Caml Light.
jjtheblunt 3y ago
genuine misunderstanding : what do you mean by "real" discriminated unions. I believe I am overlooking something (probably obvious even to me) since i know: https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/discriminated-unions https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... is perhaps a misuse of the term in this context. (I'm guessing you mean more like in Rust, but am not sure.)
- Smaug123 3y ago
  The parent comment means that C# lacks DUs, not that F# lacks them.
  - jjtheblunt 3y ago
    Oh thank you
WorldMaker 3y ago
Given few people anticipated ValueTuple and C# adding a more direct tuple syntax, I feel like it is only a matter of time before C# adds discriminated unions. (There are multiple proposals tracking the idea. This seems the most comprehensive and "central": https://github.com/dotnet/csharplang/issues/7016 https://github.com/dotnet/csharplang/issues/7016)
- chem83 3y ago
  This seem to be a longer running one: https://github.com/dotnet/csharplang/issues/113 https://github.com/dotnet/csharplang/issues/113
keithnz 3y ago
you can easily do them, I added a comment on the article showing how.... https://github.com/linkdotnet/Blog.Discussions/discussions/73#discussioncomment-6663149 https://github.com/linkdotnet/Blog.Discussions/discussions/7...
- LelouBil 3y ago
  It's just like in Kotlin !
- Turskarama 3y ago
  It's missing the killer feature though, which is the compiler warning you when you haven't done an exhaustive match. That is the magic which makes adding new values easy instead of hunting through code to find if you missed the new case anywhere.
  - mycall 3y ago
    I've only needed discriminated unions inside C# when I'm using pinvoke to C DLLs. I would think Rosylin supports some compiler warning for them, but I haven't checked that.
  - keithnz 3y ago
    I used to think that.... but actually, in practice, and I've been using them for a long time now, it doesn't make much difference, good tooling will generate the cases and help you find all instances pretty quick (I use Rider).
- Rapzid 3y ago
  My guess is roles will land first in C#13. Is is kind of a pain particularly when working across Typescript projects. OneOf is cool, but it DOES NOT work well with null and thus optional parameters.
- rjbwork 3y ago
  This is the kind of OG way to do it even before we had patterns. There are a couple of problems with it, least of which is that I can't then use one or both of those in a wider union elsewhere, because their definitions are bound to that parent class. Ideally I'd like to see something very similar to the linked OneOf library. That allows you to do both in-line definitions OR subclass from OneOf<T1,T2,T3...> to reify the union as a class as well. If that is done and integrated properly into the pattern matching system, I believe it will yield very powerful expressiveness.
ftcHn 3y ago
Agree. For now, you can get a reasonable DU via an [external library](https://github.com/mcintyre321/OneOf https://github.com/mcintyre321/OneOf). [Nick Chapsas Video on Usage](https://www.youtube.com/watch?v=7z-xjijYfcI https://www.youtube.com/watch?v=7z-xjijYfcI).