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<int> 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 the problem here, not the new switch syntax. Although he probably did it to make the example more self contained and terse.

> He's just doing too much inline

It's two short lines.

The problem is that he's writing a small but more than one line bit of code, so the overhead of the anonymous function is just as big as the code itself, and arguably more complex.

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

The conversation is quite civil already.

Ah, too late to edit/delete my comment. They edited their post, perhaps in response, which is now much more considerate.

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

    T Log<T>(string msg, Func<T> 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.

I don't know a great deal of C#, but couldn't you just do:

    T Log<T>(string msg, T result) {
        Log(msg);
        return result;
    }
    
    var result = operation switch {
        "+" => Log("addition", a + b), 
        "-" => Log("subtraction", a - b), 
        "/" => Log("division", a / b), 
        _ => throw new NotSupportedException()
    };

You already have a lambda for calling Log(), no need for a second to call the inner function. This does change the order of evaluation though.

I just mention it for academic interest. To be honest, I find the idea of passing a parameter to Log() (whether it's the value or the function) that your don't actually want logged, so that you can shoehorn two statements into an expression, abhorrent. Just write the two statements out! I think an old-fashioned switch statement is the right tool here.

I think the order of operations here is important. Take, for example, the case of operation == "/" and b == 0. You might find it valuable to log that you're doing a division, before it catches fire due to the divide by zero. Obviously a contrived example, but that was my thinking with the inner function. Either way, pretty straightforward.

>To be honest, I find the idea of passing a parameter to Log() (whether it's the value or the function) that your don't actually want logged, so that you can shoehorn two statements into an expression, abhorrent.

You've basically reimplemented Haskell's Debug.Trace[0] :)

The difference is of course that Haskell doesn't really have statements in the same way that C# does, so in Haskell it's nescessary to turn the log/trace-function into an identity function after you've applied the message-string.

I agree that it is ugly, and in any serious project I would use a proper logging setup, but I almost feel like the ugliness is a feature not a bug. It's like an extra cost when doing debug-by-print, which at least seem to keep me more mindful about cleaning up after myself.

[0] http://hackage.haskell.org/package/base-4.12.0.0/docs/Debug-...

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).

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

I couldn't agree more, {} already denotes a block of code in C#. This is more than ugly and will soon become a nightmare for maintaining code.