digitalmars.D.bugs - [Issue 11988] New: Add __switch symbol to allow retrieval of switch statement value
- d-bugmail puremagic.com (63/63) Jan 24 2014 https://d.puremagic.com/issues/show_bug.cgi?id=11988
- d-bugmail puremagic.com (11/70) Jan 24 2014 https://d.puremagic.com/issues/show_bug.cgi?id=11988
- d-bugmail puremagic.com (26/27) Jan 24 2014 https://d.puremagic.com/issues/show_bug.cgi?id=11988
- d-bugmail puremagic.com (13/22) Jan 24 2014 https://d.puremagic.com/issues/show_bug.cgi?id=11988
- d-bugmail puremagic.com (11/12) Jan 25 2014 https://d.puremagic.com/issues/show_bug.cgi?id=11988
- d-bugmail puremagic.com (13/13) Jan 29 2014 https://d.puremagic.com/issues/show_bug.cgi?id=11988
https://d.puremagic.com/issues/show_bug.cgi?id=11988 Summary: Add __switch symbol to allow retrieval of switch statement value Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: andrej.mitrovich gmail.com 12:53:42 PST --- Often you would want to use the value of the switch statement, but the only way to do this is to store the value to a variable first. This has the unfortunate effect of invading the outer scope: ----- import std.string; int get() { return 0; } void a(int) { } void b(int) { } void c(int) { } void main() { int v = get(); switch (v) { case 1: a(v); break; case 2: b(v); break; case 3: c(v); break; default: assert(0, format("Unhandled case %s", v)); } // problem: v is still visible here } ----- To avoid invading the outer scope, but at the same time avoiding introduction of arbitrary language features, it might be useful to introduce another compiler-reserved symbol "__switch". The above code would then look like: ----- import std.string; int get() { return 0; } void a(int) { } void b(int) { } void c(int) { } void main() { switch (get()) { case 1: a(__switch); break; case 2: b(__switch); break; case 3: c(__switch); break; default: assert(0, format("Unhandled case %s", __switch)); } } ----- The default diagnostic is where I've encountered a need for this feature, very frequently too. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 24 2014
https://d.puremagic.com/issues/show_bug.cgi?id=11988 monkeyworks12 hotmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |monkeyworks12 hotmail.comOften you would want to use the value of the switch statement, but the only way to do this is to store the value to a variable first. This has the unfortunate effect of invading the outer scope: ----- import std.string; int get() { return 0; } void a(int) { } void b(int) { } void c(int) { } void main() { int v = get(); switch (v) { case 1: a(v); break; case 2: b(v); break; case 3: c(v); break; default: assert(0, format("Unhandled case %s", v)); } // problem: v is still visible here } ----- To avoid invading the outer scope, but at the same time avoiding introduction of arbitrary language features, it might be useful to introduce another compiler-reserved symbol "__switch". The above code would then look like: ----- import std.string; int get() { return 0; } void a(int) { } void b(int) { } void c(int) { } void main() { switch (get()) { case 1: a(__switch); break; case 2: b(__switch); break; case 3: c(__switch); break; default: assert(0, format("Unhandled case %s", __switch)); } } ----- The default diagnostic is where I've encountered a need for this feature, very frequently too.Why don't we just allow `auto var = <expression>`, like in an if-statement? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 24 2014
https://d.puremagic.com/issues/show_bug.cgi?id=11988 13:56:44 PST ---Why don't we just allow `auto var = <expression>`, like in an if-statement?Because they would have different semantics. The if statement's body is not entered when the expression implicitly converts to false, e.g.: ----- void main() { if (auto x = 0) { assert(0); } // body not entered if (auto x = 1) { } } ----- ----- With a switch you wouldn't want this to happen. For example: void main() { switch (auto x = 0) { case 0: // this must continue to work. } } ----- So you'd end up with different semantics. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 24 2014
https://d.puremagic.com/issues/show_bug.cgi?id=11988 yebblies <yebblies gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yebblies gmail.comWho would expect 'if' and 'switch' to have the same semantics? I don't think this is worth adding a magic symbol (nested switch statements?) but switch(auto a = b) solves this quite nicely. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------Why don't we just allow `auto var = <expression>`, like in an if-statement?Because they would have different semantics. The if statement's body is not entered when the expression implicitly converts to false, e.g.: [snip] So you'd end up with different semantics.
Jan 24 2014
https://d.puremagic.com/issues/show_bug.cgi?id=11988 11:28:37 PST ---Who would expect 'if' and 'switch' to have the same semantics?Well, consistency is king. And you may introduce a bug without noticing if during refactoring you change a switch statement into an if statement. __switch might seem a bit obscure though from the way it looks.. If the different semantics of "if (auto x = ..)" and "switch (auto x = ..)" isn't really a big issue then I'm all for it. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 25 2014
https://d.puremagic.com/issues/show_bug.cgi?id=11988 Andrej Mitrovic <andrej.mitrovich gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE 00:29:57 PST --- Just realized I already have a request to allow a declaration in the switch statement, Issue 11070. *** This issue has been marked as a duplicate of issue 11070 *** -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 29 2014