January 18, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6176



--- Comment #20 from bearophile_hugs@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: -------
January 18, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6176


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com


--- Comment #21 from Andrej Mitrovic <andrej.mitrovich@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: -------
January 18, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6176



--- Comment #22 from Jonathan M Davis <jmdavisProg@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: -------
January 18, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6176



--- Comment #23 from Stewart Gordon <smjg@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: -------
January 19, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6176



--- Comment #24 from bearophile_hugs@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: -------
1 2 3
Next ›   Last »