Live data from Hacker News

C# 8: Switch expressions

alexatnet.com

71–80 of 124 posts

Re: C# 8: Switch expressions

#71
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…

it sounds like it does a "best effort" and then gives up, unfortunately, the article doesn't describe exactly to what lengths it goes here.

Re: C# 8: Switch expressions

#72

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…

We could go with a language with just if statements, while statements, function calls and "return" and be extremely easy to jump into. :)

While a bit snarky I do think it is one of the fundamental problems with programming language innovation. No matter how smart we are, learning is effortful. And we frequently judge languages not by how productive it is, but by how quickly we can start feeling productive in it. Which often preferences familiar concepts over more powerful concepts.

There is a very long feedback loop in properly evaluating a language. At least 1-2 years. You need not just figure out how to do what you already know in the language, you need to learn the new way to think in the language. And that takes time and solving lots of problems. This is only sped up if the language's concepts are kept very similar to a language you already know.

We are the bottleneck that slows down language improvement. There is no way anyone can convince me that the hodgepodge of Algol derived languages is one of the best ways out there of writing code. But most new languages will be similar because the hurdles of trying to teach people anything else alongside the actual new interesting concepts of your language are too much of a blocker for any reasonable adoption.

Re: C# 8: Switch expressions

#73
post #70
post #55

Earlier quoted context omitted.

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.

Very true.

Re: C# 8: Switch expressions

#74
In my opinion, I find the Tuple patterns the most interesting way to use Switch Expressions. But (and maybe I'm stuck in my ways), I'm kind of on the fence in terms of using this. On the one hand, it shortens some code, but on the other, it's more difficult to read than an if statement (in the case of tuples). I guess I'm not completely sold on this yet. I know the big argument in the article was that this is a way to ensure your variable has a value when you go to use it. When I hear things like that, my first reaction is "then write better code if you're running into that problem."

Re: C# 8: Switch expressions

#75

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 think I agree. I used to write a lot of C# v2 and loved it. There didn't seem to be anything 'missing'. Each version since then has added nice things but are they really necessary? Now the language looks huge and complicated and because of that, I'm not sure I'd ever want to use it again.

Re: C# 8: Switch expressions

#76
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…

Specifically, it will throw SwitchExpressionException[1]

[1] https://github.com/dotnet/corefx/issues/33284#issuecomment-4...

Re: C# 8: Switch expressions

#77

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.

Language designers are not immune to the "code must change constantly otherwise it's abandonware" mentality of today's developers.

Re: C# 8: Switch expressions

#78
post #66
post #50

Earlier quoted context omitted.

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.

But one can do

    case x:
        DoX(); goto case y;
    case y:
        DoY(); break;

Re: C# 8: Switch expressions

#79
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"

Yeah this is a feature ported from fsharp / F#, but somewhat watered down a bit to play nice with C#'s existing architectural choices.

The lineage can be further traced back to the first ML languages such as SML, and even further back to LISP and RegEx-based languages.

https://en.m.wikipedia.org/wiki/Pattern_matching

Re: C# 8: Switch expressions

#80
post #28

Earlier quoted context omitted.

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.

It's OK, it's good direction, so I won't complain.

I wouldn’t hate it. Especially since my day job has me doing a bunch of C#, anyway.
Post reply on HN