throw inside switch-expression depends on whether return value is used

[epa]

This code works:

        int x = 5;
        var dummy = x switch
        {
            1 => "hi",
            2 => "bye",
            _ => throw new Exception()
        };

However, remove the dummy variable and it no longer compiles:

        int x = 5;
        x switch
        {
            1 => "hi",
            2 => "bye",
            _ => throw new Exception()
        };

Only assignment, call, increment, decrement, await, and new object expressions can be used as a statement

This with .NET Core 3.1. This seems like a wart. I could understand it if the first example had string dummy or in some other way was providing extra type information to help the code compile. But here adding the unused return value, without specifying its type, hasn't given the compiler any information it didn't know before. It seems to violate a general principle that an expression should work the same way whether you assign its value to a variable, or ignore its return value and evaluate it for side effects only. Whether the switch-expression is valid or not shouldn't depend on something outside the expression (its assignment to a dummy variable), unless doing that provides extra type info.

I think #2632 is related but this issue may be a bit narrower. It doesn't require adding a new kind of switch statement, or supporting general statements like x=foo() on the RHS of each case, but only requires that the existing switch expressions work consistently whether the return value is assigned, or thrown away.

If I might be so bold, I'd like to suggest a general principle: if E is an expression and var dummy = (E); compiles, then E; by itself must also compile. This should hold for any new expression syntax added to the language.

[spydacarnage]

The switch expression is just that - an expression.  What you've written is the same as writing (which also doesn't compile):

5;

What does your code do (or would you want it to do if it worked) besides throw an exception if x isn't 1 or 2? You need to assign the result of the switch expression to something to make any use of it.

[foxesknow]

The switch expression is just that - an expression. What you've written is the same as writing (which also doesn't compile):

5;

What does your code do (or would you want it to do if it worked) besides throw an exception if x isn't 1 or 2? You need to assign the result of the switch expression to something to make any use of it.

True, but C# doesn't normally require you to assign the result of an expression.

What about if we've got something like this:

x switch
{
    1 => Handle_1(),
    2 => Handle_2(),
    3 => Handle_3(),
    4 => Handle_4(),
    _ => throw new Exception()
};

Should they all have to have a common return type that is assigned to a variable?

[epa]

You are right that 5; does not compile. Sorry, I was still thinking of C, where such a naked expression is permitted.

As noted, in this case I want to evaluate the expression only for its side effects. The real-world use is to validate some parameters against a set of patterns. If none of the patterns match, then an exception is thrown. An example would be checking command line parameters ("if you specify --foo-begin then you must also specify --foo-end, but if you give --ignore-baz then neither --foo option is valid, unless --force is also given....").

P.S. and although I could have used the old style switch statement, the new more concise syntax seemed appealing...

[epa]

I guess the throw part is a bit of a red herring since I see that switch expressions in general cannot be used throwing away their return value. That seems a bit awkward, but perhaps it was a deliberate choice to allow for adding switch statement expressions later? If so, perhaps a better diagnostic is all that's needed.

[epa]

@foxesknow your question about a common return type relates to #2632 I believe.

[DavidArno]

You can simply discard the value if you really don't need it:

_ = x switch
{
     1 => "hi",
     2 => "bye",
     _ => throw new Exception()
};

[epa]

In C#, as the error message says, only some kinds of expression can be used in a statement. This made sense because originally, these were the only constructs that could have side effects. Other kinds of expression would have no effect (with the possible exception of division by zero).

But with the addition of throw expressions to the language, even though they are restricted in where they can appear, we now have many more expressions that have a side effect. I would suggest updating the rule from

Only assignment, call, increment, decrement, await, and new object expressions can be used as a statement.

to

Only assignment, call, increment, decrement, await, and new object expressions, or expressions containing throw can be used as a statement.

Then in general any side-effecting expression could be used just for its side effects, if the programmer chose to: obviously it won't always be in good taste, but there are cases when it would be handy, pun not intended.

[333fred]

I'm going to leave this open, but I'll tell you now that this is something we are very unlikely to ever change. C# is very deliberate on what expressions we allow on the top level: you can see the list here. We don't want to have side-effecting expressions or expressions with no value encouraged in the language.

[333fred]

Now, switch expressions specifically, maybe we'll change. I'm personally not a fan of the top level switch expression proposal, but it is championed and I expect to discuss it for C# 10.