http://d.puremagic.com/issues/show_bug.cgi?id=6176


dawg@dawgfoto.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dawg@dawgfoto.de


--- Comment #10 from dawg@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6176


Alex Rønne Petersen <xtzgzorex@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xtzgzorex@gmail.com


--- Comment #11 from Alex Rønne Petersen <xtzgzorex@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6176


Peter Alexander <peter.alexander.au@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |peter.alexander.au@gmail.co
                   |                            |m


--- Comment #12 from Peter Alexander <peter.alexander.au@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6176



--- Comment #13 from bearophile_hugs@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6176



--- Comment #14 from Don <clugdbug@yahoo.com.au> 2012-01-16 14:40:36 PST ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6176



--- Comment #15 from dawg@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6176



--- Comment #16 from bearophile_hugs@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6176



--- Comment #17 from Stewart Gordon <smjg@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6176



--- Comment #18 from bearophile_hugs@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6176



--- Comment #19 from Jonathan M Davis <jmdavisProg@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: -------