Make DU types easier to use (correctly) in C#, add switch and match methods on root type

[smoothdeveloper]

I encountered https://github.com/mcintyre321/OneOf which allow to do exhaustive matching (without pattern matching) on a OneOf generic types with different arities.

`The suggestion is to add Match and Switch methods:

For option type, using from C#:

FSharpOption<string> opt = ...
opt.Switch(
  some => {} // value deconstruction
  , () => {} // none case
);

string result = opt.Match(
  some => some
  , () => "default"
);

Pros and Cons

The advantages of making this adjustment to F# are

• better adoption and usage of F# DUs in C# codebases

The disadvantages of making this adjustment to F# are

• depending on the implementation a bit more boiler plate code in assemblies

Extra informtion

Estimated cost : M

Related suggestions: dotnet/fsharp#1254

Affadavit

Please tick this by placing a cross in the box:

• This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
• I have searched both open and closed suggestions on this site and believe this is not a duplicate
• This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:

• This is not a breaking change to the F# language design
• I would be willing to help implement and/or test this
• I or my company would be willing to help crowdfund F# Software Foundation members to work on this

[vasily-kirichenko]

I think a better way is to make F# DUs pattern matchable with C#'s match expression.

[cartermp]

Ultimately I believe this area (making DUs easily-consumable in C# and VB) is going to be driven by the C# design team (ping @MadsTorgersen) and the .NET API team (ping @terrajobst). We could make as many changes as we like to make to DUs more easily consumable from C# and VB, but serious use of DUs in C# and VB would have to be driven by a desire from the language and .NET to make those types first-class. I believe the decision-making process would look something like this:

1. Are records/DUs something that solves a big problem with C# and VB users, and will they really want to use those types?
2. Is it desirable to take some of these types from FSharp.Core and add them to .NET?
3. Is it desirable from the .NET side to add more overloads to .NET APIs to now use these types, and change guidance to prefer using these over previous patterns (e.g., out parameters and C#7/VB15 tuples for TryParse methods)?

The proposal so far helps cure some awkwardness in libraries like OneOf, which is fine, but I would caution against further modifications until something like DUs materializes more on the C# and .NET side. Without the language features and APIs in .NET to make DUs awesome, I don't see why a C# consumer would want to consume an F# DU.

[dsyme]

Closing this old proposal