Hacker News new | past | comments | ask | show | jobs | submit login

With C# 8 you can also write it as:

  public static double ComputeArea(object shape) =>
    shape switch
    {
      Square s => s.Side * s.Side,
      Circle c => c.Radius * c.Radius * Math.PI,
      Rectangle r => r.Height * r.Length
      _ => throw new ArgumentException(
             message: "shape is not recognized",
             paramName: nameof(shape))
    };



Their long game is to slowly convert C# into F# without anyone realizing it. They're roughly half way through already.


From the features they are porting into the language I think this is the case; albeit C# will always be the more verbose language and the features will feel somewhat clunky at times IMO. Pattern matching, async yield return, async/await, etc all were in F# in some form beforehand with features like records and DU's probably being investigated as well. When I read a new C# language version announcement it does feel like I'm reading a subset of the F# feature list.


I used Scala for a bit and then came back to C# and felt like they were porting over all the Scala features, but I think the F# explanation may make more sense.


And also to mention they're lagging behind F# by almost a decade. I can find articles on discriminated unions from 2012.


Well C# 7.2 and 7.3 was moving it more to Rust. So that F# statement is a bit limited. They steal best ideas from everywhere and integrate it into the multi-paradigm language C# actually is.

In 2020 Pattern Matching is just a elementary feature everyone wants to have in all general purpose language. Like async/await. Or LINQ. That is just 101 for languages from now on.


More into D, Modula-3, Active Oberon actually.


  public static double ComputeArea(object shape) => 
    shape switch { 
      Square s => s.Side * s.Side, 
      Circle c => c.Radius * c.Radius * Math.PI, 
      Rectangle r => r.Height * r.Length,
      _ => throw new ArgumentException( message: "shape is not recognized", paramName: nameof(shape)); 
  }


Sorry, I couldn't figure out how to write a code block.


Two spaces in front of each line


There are also linters [0] available for checking that your cases are exhaustive, which can even be configured to emit the lack of exhaustive checking as an error, rather than just a message or warning.

[0] Roslyn Analyzers: https://docs.microsoft.com/en-us/visualstudio/code-quality/r...


Is `match` a reserved word in C#? I don't use it that much, but have used scala and F# pattern matching and they all use the term `match`, which seems more intuitive.


It's not reserved (and that's probably why it's not used). Most teams working on languages with a decently long history are very reluctant to add new keywords, because it will break preexisting code. `match` is a very common variable name, not only in relation to regexes. There are of course ways to do contextual parsing so that you can introduce new keywords (I believe this was done in C# with the LINQ extensions), but it complicates things for all eternity, so you want to avoid it.


C# isn't too hesitant to introduce new keywords because it supports contextual keywords.[0] Many C# keywords are also valid identifiers. In this case, using `match` in place of `where` probably wouldn't have introduced any incompatibilities.

In fact, `where` isn't a reserved keyword, either--you can have an identifier named `where`.[1]

To an existing C# programmer, `where` makes a lot of sense, since it's used for matching elsewhere (e.g., LINQ).

[0]: https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

[1]: https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...


C# has never added new reserved keywords. All keywords added after 1.0 are contextual and can still be used as identifiers. With some things like nameof, they even get their special meaning only if there's nothing else of that name that could be called. They take backwards compatibility of existing code quite serious. In fact, the only instance I can remember where C# had a breaking change was in C# 5 with how the foreach loop variable interacted with closures. The probability of code existing that relied on the old behaviour is probably really low, though.


There have been breaking API changes--.NET Core and the upcoming .NET 5 being good examples--but they're generally handled well. I can't recall any major breaking language changes, though.

They don't let backwards compatibility keep them from introducing new features and syntaxes, which is quite nice. Most languages that want to avoid breaking backwards compatibility seem too hesitant to introduce new language features.


That's why I was referring to C#, not .NET.


"where" is for match guards. Do you mean use "match" instead of "switch"? Given that the statement construct is already called "switch", it makes sense that the expression form doesn't try to use a different keyword for what is largely the same thing.


I agree, which is why I assumed the parent was referring to `where` rather than `switch`.


Nice, better than having a return statement for every case.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: