Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C# 8: Switch expressions

alexatnet.com

Post reply on HN
Print view View original

61–70 of 124 posts

Re: C# 8: Switch expressions

#61

Post by dgritsko »

platz wrote: 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.

This page[1] (which was linked elsewhere in the thread) provides the following info:

> Since an expression needs to either have a value or throw an exception, a switch expression that reaches the end without a match will throw an exception. The compiler does a great job of warning you when this may be the case, but will not force you to end all switch expressions with a catch-all: you may know better!

I haven't used the feature yet myself, so I can't say it definitively - but it sounds like it does provide compile time feedback while still allowing you to compile.

[1]: https://blogs.msdn.microsoft.com/dotnet/2019/01/24/do-more-w...

Re: C# 8: Switch expressions

#62

Post by daeken »

azhenley wrote: post #8

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

Rather than adding syntax for it, the sane approach would just be to generalize the functionality.

    T Log(string msg, Func func) {
        Log(msg);
        return func();
    }

    var result = operation switch {
        "+" => Log("addition", () => a + b), 
        "-" => Log("subtraction", () => a - b), 
        "/" => Log("division", () => a / b), 
        _ => throw new NotSupportedException()
    };
This is shorter, cleaner, and how most folks would actually write something like this, I imagine.

Re: C# 8: Switch expressions

#63

Post by dgritsko »

kminehart wrote: post #59
dgritsko wrote: post #57

Earlier quoted context omitted.

> You can write C# in too many forms and I don't believe that's really good. Why not? And what, exactly, defines "too many"?

I know people meme a lot about Go and "not having generics," but I really feel that a lot of the things left out of Go have benefitted it. I've never really been able to jump into a project without a lot of mental overhead. With Go, most code everywhere is written pretty idiomatically, making it easy to approach and read. I've heard similar things about C#, but my experience hasn't been as great. This is a big proble…

I suppose, but that seems like a natural consequence of C#'s desire to move the language "forward" in terms of implementing new features (such as switch expressions or non-nullable reference types) while also maintaining backwards compatibility (for example, you can still use the non-generic "ICollection" interface if you want to). Just a different set of priorities.

Re: C# 8: Switch expressions

#64

Post by nordsieck »

dgritsko wrote: post #57
danielovichdk wrote: post #53

I am not sure I like the path c# is going down. For years the language has been trying to evolve from being aesthetic and easy to understand and read. With the functional implementations and patterns I believe the language is trying to embrace too much. This is not specific to the swith expression in this context but in general. You can write C# in too many forms and I don't believe that's really good.

> You can write C# in too many forms and I don't believe that's really good. Why not? And what, exactly, defines "too many"?

> Why not? And what, exactly, defines "too many"?

I think Scala was innovating in this respect before Kotlin ate its lunch (it may still be).

You could use Scala as everything between Java++ and Haskell--. Developers proficient in Java++ often had a difficult time understanding code written in Haskell--.

Re: C# 8: Switch expressions

#66

Post by moomin »

kibwen wrote: post #50
wongarsu wrote: post #38

Earlier quoted context omitted.

the break keyword in switch statements also allows fallthrough, allowing for a terser way to write state machines, at the cost of making the whole construct less intuitive and readable. In a switch expression of course that is moot since break is a statement, and statements can't appear in expressions.

The thrust of my above comment is largely about how the idea "enabling fallthrough" demonstrates how poorly the switch statement is usually taught: most people have an intuitive grasp of it as an alternative to if/else if, when in truth it's sugar for a jump table. Break exists to prevent fallthrough rather than enable it! And indeed fallthrough isn't useless, though decades of long experience has demonstrated that i…

Ofc, C# doesn't actually support non-trivial fall-through. You can have

x: y: DoX()

but you can't have

x: DoX() y: DoY()

at all.

Re: C# 8: Switch expressions

#67

Post by moomin »

falcrist wrote: post #56
oblio wrote: post #45

Earlier quoted context omitted.

I don't think it's Lisp envy. They're porting stuff from F#, which as far as I know is from the ML family.

This change was definitely inspired by F# (or ML ultimately). It's far from the first feature to be brought over. Look at async/await, usable tuples, lambda functions, range syntax, etc.

AFAICT, this is kind of true for a lot of F#: F# is where they do the experimentation, C# is where they do the more heavily engineered "fast" version.

Re: C# 8: Switch expressions

#68

Post by runT1ME »

danielovichdk wrote: post #53

I am not sure I like the path c# is going down. For years the language has been trying to evolve from being aesthetic and easy to understand and read. With the functional implementations and patterns I believe the language is trying to embrace too much. This is not specific to the swith expression in this context but in general. You can write C# in too many forms and I don't believe that's really good.

I agree. It has the flexibility of Scala without the extra power/abstractions Scalaa gives you. I don't love Scala's flexibility but I put up with it because of its power, the trade off isn't worth it for C# to me.

Re: C# 8: Switch expressions

#69

Post by moomin »

chrismeller wrote: post #35
martindevans wrote: post #23

Earlier quoted context omitted.

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

Ironically that’s actually also one of the key advantages of it. If you have a long string with many placeholders in it and need to add a new one in the middle... you just add it and don’t have to figure out where in the list of params to insert the new arg.

Not so nice for the next guy, though.

Re: C# 8: Switch expressions

#70

Post by moomin »

maxxxxx wrote: post #55
kolbe wrote: post #48

Earlier quoted context omitted.

I'm on your side. I've found very little use for most improvements since C# 4, but I always use literals now. Things like value tuples and string literals are huge improvements to my code's readability and flow.

Value tuples are good too. Somehow I don't seem to get too friendly with the syntax but they are very useful.

Local functions can be a serious win over the alternatives of far away functions with no closure semantics or huge lambdas.
Post reply on HN