Live data from Hacker News

C# 8: Switch expressions

alexatnet.com

21–30 of 124 posts

Re: C# 8: Switch expressions

#21
post #2

This might be better titled "C# 8: switch expressions" (edit: it was previously "statement", as the author's post is titled). Or actually, to bait a few more hn clicks (and provide a fuller description): "Pattern matching in C# 8 with switch expressions"

This might be better titled "changing things for the sake of changing things and appealing to the programming language geeks". The new syntax is not intuitive, not more readable, just a bit more terse.

Using switch as an expression makes sense, just like using if as an expression (often written as a?b:c) does. It makes it obvious that all you are doing is changing one variable, and it makes initialising constants a lot cleaner.

Once you start making switch expressions, the break keyword makes no sense. And with pattern matching the case keyword technically wouldn't be nessesary for normal switch statements already, might as well drop it for the new syntax.

I find this completely reasonable, and I think it's very readable, especially compared to the closest equivalents: putting a single switch in a function and calling that, or using nested tertiary operators:

    const sqlOp = op switch {
                    "&&" => "AND",
                    "||" => "OR",
                    _ => throw new NotSupportedException()
                  }
vs

    function getSqlOp(string op) {
      switch op {
        case "&&": return "AND";
        case "||": return "OR";
        default: throw new NotSupportedException();
      }
    }
    
    // ... far away
    const sqlOp = getSqlOp(op);
vs

    const sqlOp = op=="&&" ? "AND" : op=="||" ? "OR" : throw new NotSupportedException();

Re: C# 8: Switch expressions

#22

I'm not sure what this accomplishes over a normal ugly switch.

For various reasons, probably due to linguistics, programmers will often make dumb compromises just to avoid writing an extra few lines of code. Many of these constructs (see especially Python's new walrus operator) are trying to let people express things in the way they want so they'll write better code.

Re: C# 8: Switch expressions

#23

Earlier quoted context omitted.

This might be better titled "changing things for the sake of changing things and appealing to the programming language geeks". The new syntax is not intuitive, not more readable, just a bit more terse.

This actually seems to be somewhat of a trend in C# as of late. Ever since they introduced lambdas, really. While I use them every day, my favorite is still “replacing” String.Format with string literals. Shorter, sure, but less intuitive particularly for people coming from another language. You can do roughly the same thing in PHP with backticks, but most people avoid them for the same reasons. I’m not sure how I fe…

String.Format("Is {0} to read {2} {1} of the {3} out of place", "harder", "half", "because", "string is").

Re: C# 8: Switch expressions

#24

Earlier quoted context omitted.

This might be better titled "changing things for the sake of changing things and appealing to the programming language geeks". The new syntax is not intuitive, not more readable, just a bit more terse.

This actually seems to be somewhat of a trend in C# as of late. Ever since they introduced lambdas, really. While I use them every day, my favorite is still “replacing” String.Format with string literals. Shorter, sure, but less intuitive particularly for people coming from another language. You can do roughly the same thing in PHP with backticks, but most people avoid them for the same reasons. I’m not sure how I fe…

> but less intuitive particularly for people coming from another language

Maybe for people coming from C++, but string interpolation is a feature in Python, JavaScript, PHP, etc. It's not exactly an unusal concept (like it was back when PHP started doing it)

Re: C# 8: Switch expressions

#26
post #2

This might be better titled "C# 8: switch expressions" (edit: it was previously "statement", as the author's post is titled). Or actually, to bait a few more hn clicks (and provide a fuller description): "Pattern matching in C# 8 with switch expressions"

This might be better titled "changing things for the sake of changing things and appealing to the programming language geeks". The new syntax is not intuitive, not more readable, just a bit more terse.

More like the trend of “bolting everything they’ve ever heard on to the language spec”.

This is a half-assed, syntactically ugly implementation of case statements in functional languages like Elm or Haskell - the point of which is to cover all possible executions of a branch explicitly, to prevent runtime errors.

Re: C# 8: Switch expressions

#27
post #8

"+" => ((Func )(() => { Log("addition"); return a + b; }))(), This is incredibly ugly. Why couldn’t it be “+” => {stuff}

The correct answer to "how to run multiple commands in the statement" would have been "don't", instead of this abonimation. If you want to do multiple things, don't use a syntax designed for expressions, use a syntax that supports blocks (like, you know, regular if/else or switch statements).

Re: C# 8: Switch expressions

#28

This makes sense together with algebraic data types, but I'm not sure if that's implemented.

They’re saving ADTs for 9.0, at which point they’ll beat their chests and loudly proclaim them to be the Best Thing Ever of All Time.

Re: C# 8: Switch expressions

#29

Earlier quoted context omitted.

This actually seems to be somewhat of a trend in C# as of late. Ever since they introduced lambdas, really. While I use them every day, my favorite is still “replacing” String.Format with string literals. Shorter, sure, but less intuitive particularly for people coming from another language. You can do roughly the same thing in PHP with backticks, but most people avoid them for the same reasons. I’m not sure how I fe…

string interpolation isn't simply a wrapper around String.Format(); it also offers compile time checking which solved a real limitation of String.Format() while offering better performance than concatenation. For example: var h = "Hello "; var w = "world"; var output = String.Format("{1} {2}", h, w); output = $"{h} {w}"; Would compile fine but throw on the String.Format() line due to the typo.

I wasn’t necessarily saying it doesn’t offer any benefit, more that it’s not really a benefit that seems to benefit a lot of people. Between code intelligence tools and actually running the code you write (not even in an actual QA process, but simply executing each line) that just doesn’t seem like a big deal to me.

There are also instances where, such as with Console.Write you are now formatting a string in order to pass it into... a method that formats strings. Yes, the same benefit is still provided, but with a fairly obvious decrease in clarity and increase in redundancy.

Re: C# 8: Switch expressions

#30
post #19
post #7

// now you kind of enforced to // handle all values, otherwise // it will not compile I fail to see how it will not compile if all values are not handled. C# switch is not traditional pattern matching, because you don't get compile time feedback. Claiming that is does is disingenuous.

In TypeScript, this can be achieved using an assertion to the never type. I don't think it exists in C#, though.

They aren't real guarantees in TypeScript, because the type system doesn't guarantee anything about the actual values that are flowing through the system. i.e. you have to code everything in TypeScript and make sure everyone follows the best practices.
Post reply on HN