-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Champion: Switch expression as a statement expression #2632
Comments
Just to check, since I get confused between statement expressions and expression statements, will the following syntax by valid with this proposal: void M(bool c, ref int x, ref string s) => c switch { true => x = 1, false => s = null }; |
Is the operator for default case still the same for this scenario or this new feature?? As I understand underscore is the current operator
|
Together with exhaustiveness checks this will render existing switch statement pretty much legacy? |
@dsaf how so? You still can't have things like blocks/multi-statements in an expression-form switch. |
@CyrusNajmabadi well maybe initially but those could be added going forward. |
Non-exhaustive switches can't be written via switch expression, void M(string s) {
switch (o) {
case 1: s = "A"; break;
case 2: s = "B"; break;
}
} Unless this is allowed void M(string s) {
o switch { 1 => s = "A", 2 => s = "B" };
} (You still need to repeat the assignment.) |
In that case, they do not "render existing switch statement pretty much legacy". :) |
What happen to var a = c switch { true => x = 1, false => s = null }; ? |
It seems sensible that it'll give you a |
@DavidArno We actually could write this int x = 0;
var a = x = 1; // a is int And in the next C# I think we could possible to var a = condition ? 1 : null; // a become Nullable<int> So actually I expect that it might be possible to var a = c switch { true => x = 1, false => s = null };
// a become Nullable<int> or object or (int | string)
// then assign both x and a to 1 if true else assign both s and a to null So I just ask to make sure |
If If |
@yaakov-h It possible that it's behaviour could be As for me I hope that we should support union type and could let this syntax return union type. Or just plain |
The value of, void Foo() {}
void Bar() => Foo();
void Baz()
{
var x = Foo(); // results in error CS0815: Cannot assign void to an implicitly-typed variable
} So the same should be true of a statement expression switch expression, void Bar(bool c, ref int x, ref string s)
=> c switch { true => x = 1, false => s = null }; // all good
void Baz(bool c, ref int x, ref string s)
{
var a = switch { true => x = 1, false => s = null };
// results in error CS0815: Cannot assign void to an implicitly-typed variable
} |
c switch { true => 1, false => null }; This expression should be var a = c switch { true => 1, false => null }; // a is int? Given that var a = x = 1; // a is int Expression C# also already has the ability to ignore any return type to int Bar() => 0;
void Foo() => Bar(); So I don't think we need to limit |
Sure, c switch { true => x = 1, false => s = null }; where |
@DavidArno My point is, even in today C#. The This below is valid bool b = someCondition;
if(b = true) // valid and work, it assign true to b and then check with value of b
{
} |
@Thaina, void M(bool c, ref int x)
{
c switch { true => x = 1, false => Console.WriteLine("hello" };
} is clearer over it being a statement expression. Edited as @yaakov-h has pointed out that, since there's no common type between |
Just to clear things up a bit, the sample code @Thaina provided is already valid if you declare those variables correctly: |
@DavidArno There is common type between And in the future we might have union type like a typescript. Which should be used in this scenario As I said I just want to have clear official statement on this |
If this is not too complex we'd like to include it in C# 9.0. |
Is it still not a good idea to have switch expression with method body? var x = o switch {
Rectangle r => r.Width * r.Height,
Circle c => {
var radius = c.Diameter / 2; // allow multiple statements in one case
Debug.WriteLine(radius); // allow side effects and break points
return Math.PI * radius * radius;
},
_ => throw new NotImplementedException()
}; Switch expression as statement expression: o switch {
Foo f => {
f.Bar();
...
},
_ => {
...
}
} |
@ccarlo88 The sarcasm and abusive comments are not welcome. Please read the code of conduct here: https://dotnetfoundation.org/about/code-of-conduct Especially these parts:
There are tons of people who visit here who have differing opinions on things. Nearly all of them are able to constructively share those ideas and discuss them with others. If you cannot, please find some other place to express your negativity. |
@CyrusNajmabadi sorry for anyone who may be affected. I am just a guy (from many) who got tired since dotnet became a "foundation". |
@ccarlo88 That's fine. Just keep the tone civil from now on, and there won't be a problem. Thanks! :) |
Any update on this ? |
It would be great if people stop creating new syntax in C#. Some reasons to not implement that:
|
Yet C++ continues to evolve and gain new features and syntax, often borrowed from other languages. For example, C++20 has As long as there are friction points in the language worth addressing the language will continue to evolve. The |
@HaloFour You pointed 2 different points, syntax and features. |
I don't see much of a distinction between the two. If the existing syntax creates friction in common use cases then there is nothing wrong with introducing alternative syntax to improve the developer ergonomics and to create a pit of success. It's not all that common that a new syntax maps to completely new features that didn't already have possible solutions.
I've yet to meet a programming language that hasn't adopted additional syntax to smooth over friction in existing features. The I'm sure that there is plenty of syntax that has been added to C# over the past 22 years that you would find challenging to live without today, even if there are ways to accomplish the same exact features in C# 1.0. I'm sure that there are places in the language where you think things could be made more concise or more declarative in order to simplify tasks you commonly perform. Everyone has a different subset of features they use or want to see added. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This issue tracks the design/spec work for this feature. Please let the conversation on topic. If you want to talk about meta topics, please open a separate discussion. Thanks. |
Yes, even in C# 1.0 the
The same is true in reverse; if you don't like the evolution of C#, you can find an alternative programming language. However, I would posit that any programming language that isn't continuing to evolve and add new syntax is a dead language. Any language that has any active usage continues to evolve, including C++, COBOL, Fortran, BASIC, Lisp, SQL, Ada, Java, etc. Or you can continue to use older versions of C#. The C# language evolves fairly conservatively, features need to prove themselves worth the massive effort to be implemented, and purely syntactic changes have the highest bar. But the language is not going to simply stop evolving. |
This comment was marked as off-topic.
This comment was marked as off-topic.
I'm not certain what was unclear about my last post. If you want to discuss meta points like these, start a new discussion |
This would be super handy in unit tests with most result switch
{
int i => Assert.Equal(i, 5),
string s => Assert.Equal(s, "x"),
_ => Assert.Null(result),
} |
I like that idea. Viewing the switch statement as a state machine, it makes sense that I would sometimes want to execute code that does not have a return statement. |
Yeah, the issue that you mention looks different to me. First, why don't you use "typeof" to determine what type you are evaluating? Then you use a switch case. |
Can you demonstrate how |
Maybe I misunderstood that creepy thing... What it does look to me is receiving a generic T, and depending on T type it process something on that type.... am I wrong? Anyway, this is really creepy, looks like the typical Python crap. |
@ccarlo88 Switch expressions receive a value and allow patterns to match against it. That's been in the language a while now. This issue is the request for allowing the args of the switch expression to be void expressions, and for the switch expression to be considered a legal statement-expression (like Assert.Equal is). |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
@ccarlo88 please keep things on-topic and following the .net code of conduct. WRT the language, the group that designs the language (the LDM) is the same one that has been designing it for 25 years now, with most of the same people involved over all that time. |
This comment was marked as off-topic.
This comment was marked as off-topic.
@ccarlo88 please keep things on-topic and following the .net code of conduct. If you have feelings beyond that, please take them to some other outlet (a blog or discord channel would be better). |
This comment was marked as off-topic.
This comment was marked as off-topic.
Locking temporarily as moderation is not being listened to. |
I propose that we support a switch expression as a statement expression when every arm's expression is also a statement expression. No common type among the arms is required when used as a statement expression.
Meeting notes
https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-08-31.md#switch-expression-as-a-statement
The text was updated successfully, but these errors were encountered: