Live data from Hacker News

C# 8: Switch expressions

alexatnet.com

41–50 of 124 posts

Re: C# 8: Switch expressions

#41
post #8

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

I was also wondering why simply opening curly braces after the => was not allowed. It would be consistent with lambda syntax generally.

Re: C# 8: Switch expressions

#42

Earlier quoted context omitted.

String interpolation is more intuitive than trying to match a placeholder in the string with a list outside of the string.

I suppose that depends upon where you’re coming from. Many, many languages have an sprintf-style construct of one form or another, so I think it’s actually much more familiar to most people to have a placeholder with an optional formatter. To each their own, though.

> Many, many languages have an sprintf-style construct of one form or another, so I think it’s actually much more familiar to most people to have a placeholder with an optional formatter

Many languages also have format strings with interpolation: JavaScript, Python, Ruby, Swift, PHP, etc.

Re: C# 8: Switch expressions

#43

Earlier quoted context omitted.

String interpolation is more intuitive than trying to match a placeholder in the string with a list outside of the string.

I suppose that depends upon where you’re coming from. Many, many languages have an sprintf-style construct of one form or another, so I think it’s actually much more familiar to most people to have a placeholder with an optional formatter. To each their own, though.

Sprintf is very error prone. Maybe people are used to it but string interpolation is clearly superior because it removes a lot of potential errors. With the trend towards safer languages sprintf and similar techniques need to go away.

Re: C# 8: Switch expressions

#44

Earlier quoted context omitted.

String interpolation is more intuitive than trying to match a placeholder in the string with a list outside of the string.

I suppose that depends upon where you’re coming from. Many, many languages have an sprintf-style construct of one form or another, so I think it’s actually much more familiar to most people to have a placeholder with an optional formatter. To each their own, though.

Well, let's take the TIOBE index as a rough indicator of popularity: https://www.tiobe.com/tiobe-index/

Java, C/C++/Objective-C/Go (I'm lumping them up because they're basically C + C NextGens), Matlab, SQL, ASM don't have them.

Everything else, has them.

On the list of languages that don't have it, Java is planning to add it, I don't see the C family to change because it's very conservative, and the others are domain specific and don't care that much about string operations.

Re: C# 8: Switch expressions

#45
post #6

Earlier quoted context omitted.

Actually, I think it is rather intuitive and readable - but then again I programmed in lisp for years.

For some time, I've thought that the direction of C#'s evolution makes a lot of sense if you look at as the designers' effort to cope with Haskell envy (pattern matching, type inference (which is really just class inference), and monad comprehensions). But, it makes almost complete sense if you instead look at it as coping with Lisp envy. I'm still amazed that they managed to sneak in function literals and FEXPRs (Li…

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.

Re: C# 8: Switch expressions

#46
post #14

Though I'm sad that a lot of developers dislike scala, I'm certainly glad to see some of it's* good parts being incorporated into current and new languages: Pattern matching to various degrees in Kotlin, now C#, and soon Java 12. * I acknowledge my ignorance in thinking that scala was the first one to the table with this.

Its fair to call it the first substantive attempt to integrate a mainstream OO language with traditionally FP ideas.

That's a big part of the story here.

Re: C# 8: Switch expressions

#47
post #15
post #8

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

That is ugly. What he's doing is creating an anonymous function which takes no parameters and returns an int. That's what a Func is, and then he is executing that function, that's the () bit after })) He could write it nicer as: "+" => Add(), Where he defines add as int Add() => a + b; He's just doing too much inline, 99% of C# developers would not write code as he has done there. Its' the bloggers code style that is…

I agree with your conclusion, but let's keep the conversation civil.

Re: C# 8: Switch expressions

#48
post #12

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…

I think string interpolation is one of the best things they did to C#. String.Format is pretty error prone.

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.

Re: C# 8: Switch expressions

#49
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.

Re: C# 8: Switch expressions

#50
post #31

Earlier quoted context omitted.

The break keyword in switch statements makes sense only if the programmer considers switch as a syntax sugar for goto, which are the semantics in C. Once you have a language that doesn't use goto but that still requires breaking each switch case, the only rationale is inertia for people familiar with C. (That said, C# does have goto, right?)

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 it is the wrong default, and newer languages like Go do better by making break the default and having a dedicated fallthrough keyword for when you want it.
Post reply on HN