C# 8.0 switch expressions only work with single return statements.

[xCyborg]

Just a thought, what if instead of slowly trickling half-baked features of pattern matching, one consistent and exhaustive solution was implemented from the get-go?

Been recently reading Mads blog on MSDN and toying around with the latest C# 8 beta I could help but wonder:
Why I couldn't run this code even though it felt as the most intuitive:

//Display as an action
static void Display(object o) => o switch // or switch o give or take parentheses
{
    Point { X: 0, Y: 0 }            p => WriteLine("origin"), //    maybe ; ?
    Point { X: var x, Y: var y }    p => WriteLine($"({x}, {y})"),
    _                                 => WriteLine("unknown")
};     //Do we reall need the semicolon here?

• Why is the new pattern switch expressions only work with return context?
• Why are multi-line statements banned also?
• Is the old/new case pattern matching obsolete now?
• Why didn't you guys opted for the compact => arrow based pattern matching exclusively from the start and reserved "case" for legacy switching instead of mixing things hopelessly?
• Would it have been better if you introduced a "match" keyword altogether?

I'm sorry for the down note but I'm really questioning the decisions you've made, even syntactically return object switch looks weird and 'un-sharpy'.

[CyrusNajmabadi]

Why is the new pattern switch expressions only work with return context?

This is not the case. 'switch expressions' work anywhere you can currently use an expression.

Why are multi-line statements banned also?

Multi-line statements are not banned.

Is the old/new case pattern matching obsolete now?

Nothing has been made obsolete.

Why didn't you guys opted for the compact => arrow based pattern matching exclusively from the start and reserved "case" for legacy switching instead of mixing things hopelessly?

Because there is already a switch-statement, and we wanted a statement form to allow patterns. We also wants an expression form. The statement form was kept mostly the same as how you always write it. i.e. case ... :. The expression form was simplified as we like expressions to be generally brief.

Would it have been better if you introduced a "match" keyword altogether?

Maybe. But the decision was made that there's practically no benefit to using that keyword. we already have 'switch', and it means the right thing here, so why nto use htat?

[CyrusNajmabadi]

even syntactically return object switch looks weird and 'un-sharpy'.

Then don't use it. It's like someone who doesn't like return x ? y : z; versus using statements. If you don't like the expr form then just use the statement form (or vice versa).

[CyrusNajmabadi]

; //Do we reall need the semicolon here?

Yes. The grammar for expression-bodied members is:

```=> expr ;`

That's why you have to write void Foo() => Console.WriteLine(); instead of void Foo() => Console.WriteLine().

This just follows that same rule.

This is necessary as you could otherwise get into ambiguous situations. If you don't have the semicolon, then the next token might be viewed to be a followup token for your member's expression body.

[CyrusNajmabadi]

Note: for general discussions about hte language, i recommend gitter.im/dotnet/csharplang. it's a place more suited to discussion like this. Cheers!

[HaloFour]

Why is the new pattern switch expressions only work with return context?

You can use "switch expressions" anywhere you can use an expression:

var greeting = language switch {
    "eng" => "Hello",
    "spa" => "Hola"
};

Why are multi-line statements banned also?

Multi-line statements aren't expressions. There is a separate proposal which looks into making sequences of statements result in an expression which will enable this scenario. Otherwise, a local function will have to suffice for the time being.

Is the old/new case pattern matching obsolete now?

No, the existing switch statement remains completely valid. It has different capabilities and different syntax rules. Otherwise there is quite a bit of overlap.

Why didn't you guys opted for the compact => arrow based pattern matching exclusively from the start and reserved "case" for legacy switching instead of mixing things hopelessly?

Pattern matching has nothing to do with => or case or any of the above. Pattern matching has been explicitly designed to result in a conditional expression that can be used in many different contexts. For example, the following is the same as above:

if (object is Point { X: 0, Y: 0 } ) {
    WriteLine("origin");
}
else if (object is Point { X: var x, Y: var y }) {
    WriteLine($"({x}, {y})")
}
else {
    WriteLine("unknown");
}

Would it have been better if you introduced a "match" keyword altogether?

That keyword was on the table. So were about a dozen other permutations of the syntax. It was decided to be better to reuse the existing keyword and to make it function like an operator.

//Do we reall need the semicolon here?

Yes, when using => in an expression-bodied member the expression still must be terminated with a semicolon:

public int Add(int x, int y) => x + y; // this semicolon is still necessary

[xCyborg]

This is not the case. 'switch expressions' work anywhere you can currently use an expression.

Are you sure? Then why am I getting those squiggles?
Or did I miss something?

[stepanbenes]

@xCyborg This is not a switch expression. This is the old statement form of the switch.

[xCyborg]

even syntactically return object switch looks weird and 'un-sharpy'.

Then don't use it. It's like someone who doesn't like return x ? y : z; versus using statements. If you don't like the expr form then just use the statement form (or vice versa).

I meant more like return switch object

[xCyborg]

@xCyborg This is not a switch expression. This is the old statement form of the switch.

Yes that's what I meant, just like in Rust.

[xCyborg]

There is a separate proposal which looks into making sequences of statements result in an expression which will enable this scenario. Otherwise, a local function will have to suffice for the time being.

OK, thanks for the clarifications, I'll look for the proposal.

[HaloFour]

Try this:

public void Method(object mysteryPlanet) {
    mysteryPlanet switch {
        case Planet { index: 3 } => Console.WriteLine("Its indeed the Earth"),
        case Planet => Console.WriteLine("Its indeed a planet"),
        _ => Console.WriteLine("Not a planet")
    };
}

or you can also do this:

public void Method(object mysteryPlanet) {
    switch (mysteryPlanet) {
        case Planet { index: 3 }:
            Console.WriteLine("Its indeed the Earth");
            break;
        case Planet _:
            Console.WriteLine("Its indeed a planet");
            break;
        default:
            Console.WriteLine("Not a planet");
            break;
    }
}

[HaloFour]

OK, thanks for the clarifications, I'll look for the proposal.

#973

[jnm2]

I will say that it was very difficult for me to find docs for this syntax yesterday via Google, Microsoft and csharplang. Sharplab doesn't seem to have a branch to play with it and master didn't seem to work.

I eventually got it by trial and error and finding my way eventually to the section in the patterns proposal.

[YairHalberstadt]

Last I checked sharplab master worked

[HaloFour]

@jnm2

Looks like a lot of branches got dropped by SharpLab. There used to be a branch for recursive patterns where switch expressions worked.

Would be nice to have a branch that represents the preview.

[jnm2]

@YairHalberstadt This is what master does.

[YairHalberstadt]

Hmmm.

I somehow got it to work just over a week ago: #2155 (comment)

I wish I could remember how...

[DavidArno]

As per #2095, statement expressions are being considered for adding to the set of valid expressions within a switch expression and the switch expression will thus be a statement expression (though I'm sure that should be an expression statement) too.

Also, as the meeting notes where that was discussed say, "We like it. Not sure it will make it for C# 8.0.", thus why,

static void Display(object o) => o switch 
{
    Point { X: 0, Y: 0 } => WriteLine("origin"),
    Point { X: var x, Y: var y } => WriteLine($"({x}, {y})"),
    _ => WriteLine("unknown")
};    

doesn't work in VS2019 P2. It should (hopefully) work in a future version of C# and VS 2019.

[xCyborg]

As per #2095, statement expressions are being considered for adding to the set of valid expressions within a switch expression and the switch expression will thus be a statement expression (though I'm sure that should be an expression statement) too.

Also, as the meeting notes where that was discussed say, "We like it. Not sure it will make it for C# 8.0.", thus why,

static void Display(object o) => o switch 
{
    Point { X: 0, Y: 0 } => WriteLine("origin"),
    Point { X: var x, Y: var y } => WriteLine($"({x}, {y})"),
    _ => WriteLine("unknown")
};    

doesn't work in VS2019 P2. It should (hopefully) work in a future version of C# and VS 2019.

So cool, even if doesn't land in C# 8.0 I hope it will land in a later dot release.
Also hope (and expect) it will work for:

static void Display(object o) { 
    switch (o)
    {
        Point { X: 0, Y: 0 } => WriteLine("origin"),
        Point { X: var x, Y: var y } => WriteLine($"({x}, {y})"),
        _ => WriteLine("unknown")
    }
}

[gafter]

The work to implement this is being tracked at dotnet/roslyn#30649

[YairHalberstadt]

Multi line switch expressions, and enhanced switch statements championed at #3038

[yanivush]

Hi

I didn't get it, if I have multiple operations under same case, for example:

switch(x)
{
  case 1: 
        y = operation1;
        z = operation2;
    break;
 case 2:
    g = operation3;
 break;
default:
}

so how can I switch it to C# 8-9 switch expression?

Thank you very much..

[Richiban]

You can't, because what you've written there is not an expression. You have a series of statements in the arms of the switch, therefore the whole switch has to be in statement form.

[yanivush]

thanks..