Bug 6176 – [tdpl] Cannot use string variables in case expressions

This program fails to compile import std.stdio; void main() { string foo = "foo"; string bar = "bar"; string mrX; switch(mrX) { case foo: writeln(foo); break; case bar: writeln(bar); break; default: writeln("who knows"); } } giving this error: prog.d(12): Error: case must be a string or an integral constant, not foo If you change the variables to int, then it works, but it doesn't work with strings. According to TDPL, p. 72, "Usually case expressions are compile-time constants, but D allows variables too and guarantees lexical-order evaluation up to the first match." So, according to TDPL, this code should be valid, but it currently fails.

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.

(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

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.

(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.

(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.

(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.

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.

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.

(In reply to comment #8) > Well, it works with variables which are of type int. Wow. I just checked, and you're right. That's disturbing. Here's the code in statement.c: /* This is where variables are allowed as case expressions. */ if (exp->op == TOKvar) { VarExp *ve = (VarExp *)exp; VarDeclaration *v = ve->var->isVarDeclaration(); Type *t = exp->type->toBasetype(); if (v && (t->isintegral() || t->ty == Tclass)) { /* Flag that we need to do special code generation * for this, i.e. generate a sequence of if-then-else */ sw->hasVars = 1; if (sw->isFinal) error("case variables not allowed in final switch statements"); goto L1; } } Note that it only allows integers AND CLASSES! I think this is a *major* misfeature. But you're right, and I was wrong -- this behaviour is clearly intentional for the integer case, and it makes absolutely no sense to allow it for integers but not for strings. So TDPL, the spec, and DMD are all different from each other.

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.

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).

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

(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.

(In reply to comment #11) > 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? Switch statements are easy to reason about, because they are controlled by a single expression. If the values of the cases are allowed to vary, they are no easier to understand than a sequence of if() statements, *but* that's not what it looks like -- it's really deceptive. int a = 2; for(;;) { switch(7) { case a: return; case 7: a = 7; break; } } > 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). But functional languages don't have variables in their case statements! In this case, it's not more expressive - it's less expressive. It's simply syntax sugar for a sequence of if() statements. A switch statement says more: only one side of the comparison is varying. The restriction is useful because it allows you to think at a higher level.

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.

(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; }

(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?

(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.

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.

(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 :-)

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.

> `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.

(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?

(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.

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/17527 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB