Proposal: Enhanced switch statements #3038

333fred · 2019-12-19T00:47:02Z

Enhanced switch statments

Proposed
Prototype: Not Started
Implementation: Not Started
Specification: Not Started

Summary

This proposal is an enhancement to the existing switch statement syntax to permit switch-expression-style arms instead of using case statements. This feature is orthogonal to #3037 and can be done independently, but was conceived of as taking #3037 switch expressions and applying them to switch statements.

Motivation

This is an attempt to bring more recent C# design around switch expressions into a statement form, that can be used when there is nothing to return. The existing switch statement construct, while very familiar to C/C++ programmers, has several design choices that can feel dated by current C# standards. These include requiring break; statements in each case, even though there is no implicit fall-through in C#, and variable scopes that extend across all cases of the switch statement for variables declared in the body, but not for variables declared in patterns in the case labels. We attempt to modernize this by providing an alternate syntax based on the switch expression syntax added in C# 8.0 and improved with the first part of this proposal.

Detailed design

We enhance the grammar of switch statements, creating an alternate form based on the grammar of switch expressions. This alternate form is not compatible with the existing form of switch statements: you must use either the new form or the old form, but not both.

var o = ...;
switch (o)
{
    1 => Console.WriteLine("o is 1"),
    string s => Console.WriteLine($"o is string {s}"),
    List<string> l => {
        Console.WriteLine("o is a list of strings:");
        foreach (var s in l)
        {
            Console.WriteLine($"\t{s}");
        }
    }
}

We make the following changes to the grammar:

switch_block
    : '{' switch_section* '}'
    | '{' switch_statement_arms ','? '}'
    ;

switch_statement_arms
    : switch_statement_arm
    | switch_statement_arms ',' switch_statement_arm
    ;

switch_statement_arm
    : pattern case_guard? '=>' statement_expression
    | pattern case_guard? '=>' block
    ;

Unlike a switch expression, an enhanced switch statement does not require the switch_statement_arms to have a best common type or to be target-typed. Whether the arm conditions have to be exhaustive like a switch expression is currently an open design question. Block-bodied statement arms are not required to have the end of the block be unreachable, and while a break; in the body will exit the switch arm, it is not required at the end of the block like in traditional switch statements.

Drawbacks

As with any proposals, we will be complicating the language further by doing these proposals. In particular, we will be adding another syntactic form to switch statements that has some very different semantics to existing forms.

Alternatives

#2632: The original issue proposed that we allow C# 8.0 switch expressions as expression_statements. We had a few initial problems with this proposal:

We're uncomfortable making these a top-level statement without the ability to put more than 1 statement in an arm.
There's some concern that making an infix expression a top-level statement is not very CSharpy.
Requiring a semicolon at the end of a switch expression in an expression-statement context feels bad like a mistake, but we also don't want to convolute the grammar in such a way as to fix this issue.

Unresolved questions

Should enhanced switch statement arms be an all-or-nothing choice? ie, should you be able to use an old-style case label and a new-style arrow arm in the same statement? This proposal takes the opinion that this should be an exclusive choice: you use one or the other. This enables a debate about the second unresolved question for enhanced switch, whether they should be exhaustive. If we decide that enhanced switch should not be exhaustive, then this debate becomes largely a syntactic question.
- An important note about modern switch expression arms is that you cannot have multiple when clauses with fallthrough, like you can with traditional switch statements today. If this is an all-or-nothing choice, this means that the moment you need multiple when clauses you fall off the rails and must convert the whole thing back to a traditional switch statement.
Should enhanced switch be exhaustive? Switch expressions, where enhanced switch statements are inspired from, are exhaustive. However, while the exhaustivity makes sense in an expression context where something must be returned in all cases, this makes less sense in a statement context. Until we get discriminated unions in the language, the only times we can be truly exhaustive in C# is when operating on a closed type heirarchy that includes a catch-all case, or we are operating on a value type. And if the user is required to add a catch-all do nothing case, then purpose of exhaustivity has been largely obviated.

Design meetings

https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-08-31.md#switch-expression-as-a-statement
https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-09-26.md#discriminated-unions

The text was updated successfully, but these errors were encountered:

HaloFour · 2019-12-19T01:39:55Z

I like. It may also be a step towards making block expressions, which I personally would prefer over sequence expressions as they have been proposed.

For reference, here's the current preview switch expression syntax in Java 13. IIRC they plan on taking that syntax out of preview in Java 14 slated for release in March:

~~https://openjdk.java.net/jeps/325~~
~~https://openjdk.java.net/jeps/354~~
https://openjdk.java.net/jeps/361

// as statement
switch (p) {
    case 1 ,2, 3 -> System.out.println("Foo");
    case 4, 5, 6 -> {
        System.out.println("Bar");
    }
};

// as expression
String result = switch (p) {
    case 1 ,2, 3 -> "Foo";
    case 4, 5, 6 -> {
        yield "Bar";
    }
};

iam3yal · 2019-12-19T03:59:28Z

I'd really prefer this approach and keep the switch expression as is.

Should enhanced switch statement arms be an all-or-nothing choice?

Ideally, I'd love to mix them but because they differ syntactically and have different rules applied to them then I'd go with all-or-nothing.

An important note about modern switch expression arms is that you cannot have multiple when clauses with fallthrough, like you can with traditional switch statements today. If this is an all-or-nothing choice, this means that the moment you need multiple when clauses you fall off the rails and must convert the whole thing back to a traditional switch statement.

This can be automated.

333fred · 2019-12-19T04:49:54Z

This can be automated.

It can be automated, but it's a very ungraceful process if you find yourself in the scenario where you need multiple when clauses.

333fred · 2019-12-19T04:53:04Z

See also the discussion in ldm around making the existing switch expression an expression statement: https://github.com/dotnet/csharplang/blob/master/meetings/2019/LDM-2019-12-16.md#switch-expression-as-a-statement-expression.

iam3yal · 2019-12-19T13:31:56Z

@333fred It's very similar to LINQ where at times you need to transform query expression into a method syntax and sometimes even into a loop statement.

333fred · 2019-12-19T16:12:08Z

@333fred It's very similar to LINQ where at times you need to transform query expression into a method syntax and sometimes even into a loop statement.

I'm not saying there isn't precedent, I'm just saying that it's a very ungraceful degredation story.

Ideally, I'd love to mix them but because they differ syntactically and have different rules applied to them then I'd go with all-or-nothing.

An important note is that the differing syntax right now is due to my desire to start the discussion with exhaustive vs non-exhaustive in ldm. After we have discussion, if we come down on the non-exhaustive side my plan is to modify the syntax to be much more similar to the existing case labels, and that becomes less of a concern.

laicasaane · 2019-12-20T17:17:28Z

I personally find it quite confusing, when reading the example code, I just thought of it as switch expression. I suggest we retain the case keyword, like the Java code preview @HaloFour has posted.

0x000000EF · 2020-01-08T20:37:21Z

@333fred , seems that mixing of value and type matching at the one level is not a good practice (may breaks possible compiler optimizations related with preffered type matching).

Possible, there is a sense to split value and type matching expressions into two kinds of switch (Java style for values, true lambda style for types).

Indeed, the following code very closely with your sample may be successfully compiled and run.

Check how into dotnetfiddle.net online compiler

o.Switch
(
	(int i) => Console.WriteLine($"o is int {i}"),
	(string s) => Console.WriteLine($"o is string {s}"),
	(string[] l) =>	{
		Console.WriteLine("o is an array of strings:");
		foreach (var s in l)
		{
			Console.WriteLine($"\t{s}");
		}
	}
);

var result = o.Match
(
	(int i) => $"o is int {i}",
	(string s) => $"o is string {s}",
	(string[] l) =>	{
		var result = "o is an array of strings:\n";
		foreach (var s in l)
		{
			result += $"\t{s}";
		}
		return result;
	}
);

HaloFour · 2020-01-08T21:04:35Z

@0x000000EF

That example falls apart when combined with all of the various kinds of patterns supported in C# 8.0, not to mention the delegate invocation adds non-trivial overhead and additional allocations.

333fred · 2020-01-08T21:18:49Z

@333fred , seems that mixing of value and type matching at the one level is not a good practice (may breaks possible compiler optimizations related with preffered type matching).

@0x000000EF I have no idea what you're actually saying here. This proposal changes nothing with regards to how we emit code in any fashion, it only changes syntax and some variable lifetime rules. Everything in my examples are completely possible in switch statements today, just with a different syntax.

0x000000EF · 2020-01-09T11:48:28Z

@333fred , a false alarm.

More year ago C# compiler had a problem.
For similar code

           switch (o)
           {
                      case 1: return "one";
                      case 2: return "two";
                      case int i when i > 2: return "too many";
                      case int i: return "too few";
      
                      case "abc": return "ABC";
                      case "xyz": return "zyx";
                      case string s: return default;
      
                      case null: return "is null";
                      default: return default;
           }

it had generated optimal code something like

if (o is int) // type matching
{
    … // value matchings
}
if (o is string) // type matching
{
    … // value matchings
}

But simple reordering of cases

           switch (o)
           {
                      case 1: return "one";
                      case 2: return "two";
                      case "abc": return "ABC";
                      case "xyz": return "zyx";

                      case int i when i > 2: return "too many";
                      case int i: return "too few"; 
                      case string s: return default;
      
                      case null: return "is null";
                      default: return default;
           }

had caused non-optimal if statements.

Currently I checked compiler output and seems that this problem has been fixed and the compiler automatically perform reordering for second case.

Ok, there is not the problem anymore.

TheFanatr · 2020-11-01T09:56:55Z

Wait so did my comment and suggestions on #2636 make it into this (as it was recently closed), and if not, can it be? It is referring to being able to include block bodies for "expressional" switch branches in switch expressions as well, not just switch statements, via having another => after the block for submitting the result, so blah switch { 1 => { /*lines of code*/ } => /*result*/ }. This is to avoid having to deal with the issue of reusing return or yield in such a scenario. I realize this issue may be scoped to just the switch statement, though I hope it isn't because this lack of analog needs to be addressed anyways if the statement version makes it in, but if so, should I reopen the aforementioned issue?

YairHalberstadt · 2020-11-01T09:59:55Z

@TheFanatr

The area is pretty open for now, and the LDT is definitely considering whether blocks should be just on the statement form, on the expression form, or in general as expression blocks be allowed everywhere.

333fred · 2020-11-01T16:54:52Z

Switch expression enhancements are covered by #3037.

Dimension4 · 2020-11-19T16:50:07Z

Lets make it like in Zig and make everything an expression:

imports
if ... else ...
switch ...
loops
blocks
type declarations
function declarations

Atulin · 2021-09-06T20:37:56Z

Oof, removed from C# 10 plans... Any chance it'll be considered for the next version?

RikkiGibson · 2021-12-13T00:23:02Z

The proposal says "Prototype: Complete" at the top. Is that accurate? Is there a feature branch where a prototype lives?

333fred · 2021-12-13T01:22:49Z

The proposal says "Prototype: Complete" at the top. Is that accurate? Is there a feature branch where a prototype lives?

It is not complete.

TahirAhmadov · 2021-12-13T21:00:24Z

Meh. This really doesn't add that much value.

zhyy2008z · 2021-12-15T07:39:56Z

Cheer up, I like it very much! Please implement it as soon as possible! The old switch statement is too annoying, especially the grammatical rules of variables declaration scope, I always need to add parentheses to create local scope. The break keyword is a bit redundant, too.

zhyy2008z · 2021-12-15T14:55:21Z

Maybe it would be better to use ";" instead of "," as the separator?

var o = ...;
switch (o)
{
    1 => Console.WriteLine("o is 1");
    string s => Console.WriteLine($"o is string {s}");
    List<string> l => {
        Console.WriteLine("o is a list of strings:");
        foreach (var s in l)
        {
            Console.WriteLine($"\t{s}");
        }
    }
}

switch_block
    : '{' switch_section* '}'
    | '{' switch_statement_arms ';'? '}'
    ;

switch_statement_arms
    : switch_statement_arm
    | switch_statement_arms ';' switch_statement_arm
    ;

switch_statement_arm
    : pattern case_guard? '=>' statement_expression
    | pattern case_guard? '=>' block
    ;

marchy · 2023-06-01T21:21:17Z

Any updates on this?

We're currently using lambda helpers to replace this:

switch( authIdentity ){
case AuthIdentity.PhoneNumberIdentity phoneNumberIdentity:
	installation.SetPreAuthContextPhoneNumber( phoneNumberIdentity.PhoneNumber );
	break;
				
case AuthIdentity.MessengerIdentity messengerIdentity:
	installation.SetPreAuthContextMessengerPageScopedID( messengerIdentity.PageScopedID );					
	break;
				
default:
	throw new NotSupportedException( $"Unknown auth identity {typeof(AuthIdentity)}" ),
}

with this:

object _ = authIdentity switch {
	AuthIdentity.PhoneNumberIdentity phoneNumberIdentity => Do( () => {
		installation.SetPreAuthContextPhoneNumber( phoneNumberIdentity.PhoneNumber );
	}),
	AuthIdentity.MessengerIdentity messengerIdentity => Do( () => {
		installation.SetPreAuthContextMessengerPageScopedID( messengerIdentity.PageScopedID );
	}),
	_ => throw new NotSupportedException( $"Unknown auth identity {typeof(AuthIdentity)}" ),
}

This uses the following lambda helper (which is useful in all sorts of other contexts):

/// <summary>
/// Performs the given action, returning the 'no-op' result (fundamental C# limitation).
/// </summary>
/// <param name="action"></param>
/// <returns>NOTE: This object represents 'Void' – containing a "no result' result</returns>
[DebuggerStepThrough]
public static /*void*/object Do( Action action ){
	action();
	return new object();
}

There is some ugliness needed with the object _ = because C# doesn't let the switch expression get invoked without assigning it to an object (ie: purely for the side-effects) - which is another annoying/unnecessary limitation.

It would be fantastic having this as out-of-box language support. It's not only used for multi-line statements, but even single-line statements that invoke different logic/methods, as shown in the example.

KennethHoff · 2023-07-13T15:00:34Z

@marchy could this workaround be improved by this suggestion? Allowing you simply write

_ => Do({
    // Logic
    }),

#6122

eduarddejong · 2024-02-07T13:17:00Z

Once again I think Rust can also be a great inspiration for other languages.
Every statement in Rust is also a value returning expression. It's all very consistent and simple.

What I am talking about:
https://doc.rust-lang.org/book/ch06-02-match.html
https://doc.rust-lang.org/stable/reference/expressions/match-expr.html

Read match just as switch, it's the same concept.

It shows how a language can just have 1 single kind of construct for everything.

However, in Rust the last line where you leave the semicolon open is the one which yields a value, which I would not want to suggest for C# where as it is not idiomatic.

I would just say the yield keyword is beautiful to return values just like Java. Or maybe yield return, but that probably conflicts with the current iterator usage.

rutgersc · 2024-04-07T19:07:48Z

Is there any update on this?

As @eduarddejong mentions, there are other languages that have none of these issues, where they either require everything to have a return value, or some kind of (or lack of) identifier to signal the return value.

The Do() helper is not really a decent workaround though unfortunately, might as well use the old switch statements.

CyrusNajmabadi · 2024-04-07T19:09:53Z

@rutgersc When updates happen, these issues are updated. No need to ask :)

333fred added Proposal Proposal champion labels Dec 19, 2019

333fred self-assigned this Dec 19, 2019

333fred mentioned this issue Dec 19, 2019

Champion: Switch expression as a statement expression #2632

Closed

gafter added this to the 9.0 candidate milestone Jan 7, 2020

MadsTorgersen mentioned this issue Jan 8, 2020

Proposal: Expression blocks #3086

Open

jcouv modified the milestones: 9.0 candidate, 10.0 candidate Apr 22, 2020

333fred modified the milestones: 10.0 candidate, 10.0 Working Set Sep 9, 2020

YairHalberstadt mentioned this issue Nov 1, 2020

Support for Block Bodied Switch Expression Branches #2636

Closed

MadsTorgersen mentioned this issue Nov 16, 2020

Planning: Working Set Themes #4144

Closed

RenderMichael mentioned this issue Oct 27, 2023

RFC: Add a Unit type to the System namespace dotnet/runtime#33083

Open

dotnet locked and limited conversation to collaborators Nov 18, 2024

333fred converted this issue into discussion #8608 Nov 18, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

This issue was moved to a discussion.

Proposal: Enhanced switch statements #3038

Proposal: Enhanced switch statements #3038

333fred commented Dec 19, 2019 •

edited

Loading

HaloFour commented Dec 19, 2019 •

edited

Loading

iam3yal commented Dec 19, 2019

333fred commented Dec 19, 2019

333fred commented Dec 19, 2019

iam3yal commented Dec 19, 2019

333fred commented Dec 19, 2019

laicasaane commented Dec 20, 2019 •

edited

Loading

0x000000EF commented Jan 8, 2020

HaloFour commented Jan 8, 2020

333fred commented Jan 8, 2020

0x000000EF commented Jan 9, 2020 •

edited

Loading

TheFanatr commented Nov 1, 2020 •

edited

Loading

YairHalberstadt commented Nov 1, 2020

333fred commented Nov 1, 2020 •

edited

Loading

Dimension4 commented Nov 19, 2020

Atulin commented Sep 6, 2021

RikkiGibson commented Dec 13, 2021

333fred commented Dec 13, 2021

TahirAhmadov commented Dec 13, 2021

zhyy2008z commented Dec 15, 2021 •

edited

Loading

zhyy2008z commented Dec 15, 2021

marchy commented Jun 1, 2023 •

edited

Loading

KennethHoff commented Jul 13, 2023

eduarddejong commented Feb 7, 2024

rutgersc commented Apr 7, 2024 •

edited

Loading

CyrusNajmabadi commented Apr 7, 2024

This issue was moved to a discussion.

This issue was moved to a discussion.

Proposal: Enhanced switch statements #3038

Proposal: Enhanced switch statements #3038

Comments

333fred commented Dec 19, 2019 • edited Loading

Enhanced switch statments

Summary

Motivation

Detailed design

Drawbacks

Alternatives

Unresolved questions

Design meetings

HaloFour commented Dec 19, 2019 • edited Loading

iam3yal commented Dec 19, 2019

333fred commented Dec 19, 2019

333fred commented Dec 19, 2019

iam3yal commented Dec 19, 2019

333fred commented Dec 19, 2019

laicasaane commented Dec 20, 2019 • edited Loading

0x000000EF commented Jan 8, 2020

HaloFour commented Jan 8, 2020

333fred commented Jan 8, 2020

0x000000EF commented Jan 9, 2020 • edited Loading

TheFanatr commented Nov 1, 2020 • edited Loading

YairHalberstadt commented Nov 1, 2020

333fred commented Nov 1, 2020 • edited Loading

Dimension4 commented Nov 19, 2020

Atulin commented Sep 6, 2021

RikkiGibson commented Dec 13, 2021

333fred commented Dec 13, 2021

TahirAhmadov commented Dec 13, 2021

zhyy2008z commented Dec 15, 2021 • edited Loading

zhyy2008z commented Dec 15, 2021

marchy commented Jun 1, 2023 • edited Loading

KennethHoff commented Jul 13, 2023

eduarddejong commented Feb 7, 2024

rutgersc commented Apr 7, 2024 • edited Loading

CyrusNajmabadi commented Apr 7, 2024

This issue was moved to a discussion.

333fred commented Dec 19, 2019 •

edited

Loading

HaloFour commented Dec 19, 2019 •

edited

Loading

laicasaane commented Dec 20, 2019 •

edited

Loading

0x000000EF commented Jan 9, 2020 •

edited

Loading

TheFanatr commented Nov 1, 2020 •

edited

Loading

333fred commented Nov 1, 2020 •

edited

Loading

zhyy2008z commented Dec 15, 2021 •

edited

Loading

marchy commented Jun 1, 2023 •

edited

Loading

rutgersc commented Apr 7, 2024 •

edited

Loading