[Issue 6176] [tdpl] Cannot use string variables in case expressions
https://issues.dlang.org/show_bug.cgi?id=6176 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --
[Issue 6176] [tdpl] Cannot use string variables in case expressions
https://issues.dlang.org/show_bug.cgi?id=6176 Sobirari Muhomori dfj1es...@sneakemail.com changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=14931 --
[Issue 6176] [tdpl] Cannot use string variables in case expressions
https://issues.dlang.org/show_bug.cgi?id=6176 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Version|unspecified |D2 --
[Issue 6176] [tdpl] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176
--- Comment #16 from bearophile_h...@eml.cc 2012-01-18 04:40:14 PST ---
(In reply to comment #13)
There are two very different use cases in D here.
An option is to add another kind of switch attribute:
enum switch (foo) {
case c1: break; // all c1,c2 must be a compile-time constants
case c2: break;
default: break;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6176] [tdpl] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176
--- Comment #17 from Stewart Gordon s...@iname.com 2012-01-18 06:45:23 PST ---
(In reply to comment #16)
(In reply to comment #13)
There are two very different use cases in D here.
An option is to add another kind of switch attribute:
enum switch (foo) {
case c1: break; // all c1,c2 must be a compile-time constants
case c2: break;
default: break;
}
We already have an enum switch - it's called final switch. Inventing something
new and calling it enum switch will be confusing. What would it be anyway -
just an optional check for the programmer similar to the override attribute?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6176] [tdpl] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176 --- Comment #18 from bearophile_h...@eml.cc 2012-01-18 09:53:06 PST --- (In reply to comment #17) We already have an enum switch - it's called final switch. The purpose of this idea is different. A final switch requires to list all possibilities and it forbids the default case. Inventing something new and calling it enum switch will be confusing. I see. What would it be anyway - just an optional check for the programmer similar to the override attribute? override will stop being optional, see issue 3836. Likewise this was not meant to be optional, eventually. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6176] [tdpl] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176 --- Comment #19 from Jonathan M Davis jmdavisp...@gmx.com 2012-01-18 10:01:02 PST --- Personally, I think that simplest and best solution is to just restrict case statements to compile-time constants like every language does. I agree with Don that this feature is a misfeature. We already have if-else-if chains for the general case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6176] [tdpl] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176 --- Comment #20 from bearophile_h...@eml.cc 2012-01-18 10:06:02 PST --- (In reply to comment #19) Personally, I think that simplest and best solution is to just restrict case statements to compile-time constants like every language does. I agree :-) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6176] [tdpl] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #21 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-01-18
10:16:13 PST ---
Switch allows more funky code:
import std.stdio;
string a() { return a; }
void main()
{
switch (a) {
case a():
writeln(true);
default:
}
}
and:
import std.stdio;
int foo() { return 1; }
void main()
{
int x;
switch (x = foo())
{
default:
}
}
`if (x = foo())` can't work, so I don't know why `switch (x = foo())` can.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6176] [tdpl] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176 --- Comment #22 from Jonathan M Davis jmdavisp...@gmx.com 2012-01-18 13:50:26 PST --- `if (x = foo())` can't work, so I don't know why `switch (x = foo())` can. That's easy. With if, there's a strong possibility that the programmer really meant to use ==. So, by disallowing = by itself, you avoid those bugs (though it would certainly be nice to be able to do if(x = foo()) - gcc allows it without complaining if you add extra parens (though IIRC Visual Studio doesn't like it) - if((x = foo()) - but I don't think that D has anything of the sort). However, the switch statement requires a value, not an expression, so the risk of = being used instead of == is pretty much zero. So, disallowing it for switch doesn't really benefit anyone. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6176] [tdpl] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176 --- Comment #23 from Stewart Gordon s...@iname.com 2012-01-18 15:26:46 PST --- (In reply to comment #18) What would it be anyway - just an optional check for the programmer similar to the override attribute? override will stop being optional, see issue 3836. Likewise this was not meant to be optional, eventually. This wouldn't make sense - why should I be forced to add something just to show I know that all the case values are compile-time constants? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6176] [tdpl] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176 --- Comment #24 from bearophile_h...@eml.cc 2012-01-18 16:06:09 PST --- (In reply to comment #23) This wouldn't make sense - why should I be forced to add something just to show I know that all the case values are compile-time constants? Let's assume in one case you want the compiler to produce a very efficient switch, maybe because you are writing the main loop of a little interpreter. In this case you don't want one of the cases to be on a runtime value _by your mistake_, because this may break this compiler optimization, forcing a less efficient compilation of the switch. So to be sure you are not doing such mistakes, you add an annotation to the switch, and the compiler catches your mistakes. In the end I agree this is probably not necessary, and it's better for switch cases to be required to always be compile-time constants, losing a bit of switch flexibility. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6176] [tdpl] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176
--- Comment #15 from d...@dawgfoto.de 2012-01-17 19:47:59 PST ---
Some argumentation in favor of a dynamic switch
switch (receive(ch0, ch1, ch2))
{
case ch0:
writeln(ch0.get());
break;
case ch1:
writeln(ch1.get());
break;
case ch2:
writeln(ch2.get());
break;
default:
// error
break;
}
auto token = nextToken();
switch (token)
{
case lastToken:
break;
case A: .. case B:
}
lastToken = token;
switch (str)
{
case re([f|b]oo):
case re([f|b]ar):
case re([f|b]az):
}
This can definitely become very confusing, e.g. when the
comparison has the side-effect of changing another case label.
To make it complete a dynamic case statement should be a boolean
expressions probably involving the expression being switch on,
i.e. the perfect dynamic switch is an if-else chain.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6176] [tdpl] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176 d...@dawgfoto.de changed: What|Removed |Added CC||d...@dawgfoto.de --- Comment #10 from d...@dawgfoto.de 2012-01-15 08:53:58 PST --- There is definitely some value to allow this for strings, e.g. when you want use strings from translation files or allow user definable commands. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6176] [tdpl] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176 Alex R�nne Petersen xtzgzo...@gmail.com changed: What|Removed |Added CC||xtzgzo...@gmail.com --- Comment #11 from Alex R�nne Petersen xtzgzo...@gmail.com 2012-01-15 09:54:54 PST --- I'm just going to interject here. I don't understand why anyone sees the need to limit the switch construct in any way. Why force it to use compile-time values? Why force it to support primitives only? A full-blown, generalized switch would greatly improve D's expressiveness, and would cater to functional programmers. Functional languages have shown that pattern matching (which is essentially just a generalized switch, or -- as I like to call it -- switch done *right*) is extremely useful to write short and concise code, especially the ML family of languages (SML, OCaml, F#, etc). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6176] [tdpl] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176 Peter Alexander peter.alexander...@gmail.com changed: What|Removed |Added CC||peter.alexander...@gmail.co ||m --- Comment #12 from Peter Alexander peter.alexander...@gmail.com 2012-01-15 10:24:44 PST --- I added a pull request to update the documentation to align with TDPL. https://github.com/D-Programming-Language/d-programming-language.org/pull/60 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6176] [tdpl] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176 --- Comment #13 from bearophile_h...@eml.cc 2012-01-15 11:11:43 PST --- (In reply to comment #11) I don't understand why anyone sees the need to limit the switch construct in any way. There are two very different use cases in D here. If you want to implement a C-style finite state machine switching on a enum integer you want the compiler to squeeze of the very last bit of performance out of the code. If you are writing functional-style code in a not performance-critical part of the program you prefer a very flexible switch. In theory a well implemented switch is able to work for both use cases, but compiler practice is often different from theory, and what is good for single-instruction-conscious code is often not the best for the other use case. Requiring all switch cases to be compile-time constants gives some guarantees. Sometimes you only think a value is a compile-time constant, while it is not, and if the compiler doesn't warn you, you risk having a lower performance. Strings at compile-time in theory allow the compiler to use smarter and more faster strategies to find the various cases. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6176] [TDPL] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #7 from Don clugd...@yahoo.com.au 2011-07-08 01:03:36 PDT --- This must be a mistake in TDPL, or just poor wording. It's true that DMD does relax the rule on compile-time strings, to include global variables which are initialized in static this(). But it doesn't include _all_ variables. It's pretty clear that the unqualified description in TDPL (D allows variables too) cannot be correct. What if it's a shared variable, for example? Note that defining it as requiring a compile-time constant allows CTFE to be used. If variables are permitted, then the rules become more complicated, not simpler. Allowing variables would be an appallingly bad feature. It would mean that to understand control flow in a function which contains a switch, you need to check every 'case' statement to see if it's a variable, and then you need to check if that variable can change from inside the function. That's a huge change from the existing language, where you know that the control expression is the only thing that affects control flow. This is far worse for code maintenance and readability than 'goto'. Effectively, this would remove the 'switch' statement from the language. Switch would become nothing more than syntax salt for a sequence of 'if' statements. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6176] [TDPL] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176 --- Comment #8 from Jonathan M Davis jmdavisp...@gmx.com 2011-07-08 01:13:14 PDT --- Well, it works with variables which are of type int. TDPL claims that it works with variables, and switch statements work with integral types and strings. So, per TDPL, switch statements should work with string variables. Now, personally, I'm very surprised that _any_ type of variable would be permitted as the value of a case statement under any circumstances, and it wouldn't hurt my feelings one whit if it were removed from the language completely. I see no value in such a feature. However, TDPL is pretty clear about allowing variables, so it certainly didn't get in there by accident (and using integer variables _does_ currently work). So, it's fine with me if this is declared as an errata for TDPL, but I don't think that it's a case of TDPL being unclear. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6176] [TDPL] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176 --- Comment #6 from Stewart Gordon s...@iname.com 2011-06-20 15:11:09 PDT --- (In reply to comment #5) (In reply to comment #4) If the case values are all constant, create this tree. Otherwise, just compare the switched value with the cases individually. This is possible, of course, it just requires a bit more complex compiler. But the extra complexity is nothing compared to implementing the tree optimisation in the first place. Moreover, ISTM for switches with only a few values, comparing the cases individually might be actually more efficient. So this extra complexity might actually be needed in order not to pessimise these simpler cases. A problem: if one of your strings are not compile-time const, because of a mistake of the programmer, there is a silent and invisible loss of performance. Which is to be expected. After all, compiler optimisation is a privilege, not a right. Though adopting the aforementioned mixture of the two approaches would mean that any loss of performance would be small. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6176] [TDPL] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176 Stewart Gordon s...@iname.com changed: What|Removed |Added Keywords|rejects-valid |spec CC||s...@iname.com Severity|normal |enhancement --- Comment #1 from Stewart Gordon s...@iname.com 2011-06-19 10:39:42 PDT --- http://www.digitalmars.com/d/1.0/statement.html#CaseStatement The case expressions must all evaluate to a constant value or array. They must be implicitly convertible to the type of the switch Expression. http://www.digitalmars.com/d/2.0/statement.html#CaseStatement The case expressions must all evaluate to a constant value or array, or a runtime initialized const or immutable variable of integral type. They must be implicitly convertible to the type of the switch Expression. So the code is illegal. Clearly this is a mistake in TDPL. Though I am made to wonder why this restriction is there. Changing to enhancement for the meantime. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6176] [TDPL] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #2 from bearophile_h...@eml.cc 2011-06-19 11:20:58 PDT --- (In reply to comment #1) Though I am made to wonder why this restriction is there. The purposes of a switch are to give a ordered syntax to manage several value cases (final switches are able to catch some bugs too), and to compile to efficient code, sometimes a complex mix of dispatch tables and hard-coded search trees (and more, if the compiler is smart, doing automatically one of the purposes of computed gotos). I think currently DMD doesn't optimize string switches a lot, but it's not hard to think about it using a hard-coded trie, some kind of digital tree, perfect hashing, etc. Compile-time constants allow to create such optimized code. See also bug 5862 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6176] [TDPL] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added Keywords|spec|rejects-valid Severity|enhancement |normal --- Comment #3 from Jonathan M Davis jmdavisp...@gmx.com 2011-06-19 12:16:52 PDT --- Not to be rude, but I'm changing it back to a bug. If TDPL says something, and the compiler or online documentation doesn't agree, then it's a bug until Walter decides that we're not following what TDPL says. The rule is essentially that TDPL is always right unless Walter decides otherwise. It doesn't matter what the online docs say except that if they contradict TDPL, then they're also wrong until Walter decides that what TDPL says shouldn't be correct. So if anything, at the moment, it's a bug in the spec in addition to the bug in the compiler, not an enhancement. And remember that this _does_ currently work with variables of type int. So, the spec doesn't match what the compiler is currently doing anyway. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6176] [TDPL] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176 Stewart Gordon s...@iname.com changed: What|Removed |Added Keywords||spec --- Comment #4 from Stewart Gordon s...@iname.com 2011-06-19 13:45:32 PDT --- (In reply to comment #2) I think currently DMD doesn't optimize string switches a lot, but it's not hard to think about it using a hard-coded trie, some kind of digital tree, perfect hashing, etc. Compile-time constants allow to create such optimized code. But that doesn't mean it would have to _always_ use a hard-coded tree. It goes without saying that an optimisation can happen only if the criteria for it to make sense are satisfied. Let F be the overall feature being considered, and S be the subset of this feature that can be optimised in a certain way. Why contrive F to equal S, when you can implement a non-empty F \ S just without the optimisation? If the case values are all constant, create this tree. Otherwise, just compare the switched value with the cases individually. Later on, we could improve it to use a mixture of the two approaches where some but not all cases are CTCs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6176] [TDPL] Cannot use string variables in case expressions
http://d.puremagic.com/issues/show_bug.cgi?id=6176 --- Comment #5 from bearophile_h...@eml.cc 2011-06-19 16:23:49 PDT --- (In reply to comment #4) If the case values are all constant, create this tree. Otherwise, just compare the switched value with the cases individually. This is possible, of course, it just requires a bit more complex compiler. A problem: if one of your strings are not compile-time const, because of a mistake of the programmer, there is a silent and invisible loss of performance. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
