www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - About switch case statements...

reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
So, switch-case statements are a frequent source of nasty bugs.  Fixing
them (well) requires breaking backwards compatibility.

Any chance this will happen for D2?

(This is intended as more of a reminder and simple curiosity than a
discussion.)
Nov 15 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Chad J wrote:

 So, switch-case statements are a frequent source of nasty bugs.  Fixing
 them (well) requires breaking backwards compatibility.
 
 Any chance this will happen for D2?
 
 (This is intended as more of a reminder and simple curiosity than a
 discussion.)


I wish very much that a transferring control flow statement (break, 
return, goto etc.) is required at the end of each case. Then, the rare 
case when you want to break through is easy to implement as goto case 
xxx; and all is good.

Walter's answer to that has put me to silence for good. "But I use 
fall-through all the time!" I then knew the feature will never make it.


Andrei
Nov 15 2009
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-11-15 12:54:02 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 Walter's answer to that has put me to silence for good. "But I use 
 fall-through all the time!" I then knew the feature will never make it.


Hum two suggestions. Sometime I want fall-through when I write a 
switch, but I always make it clear that it isn't a bug by writing the 
intent in a short comment:

	switch (c) {
		case 1:
			blah();
			break;
		case 2:
			blah();
			// fallthrough
		case 3:
			blah();
			break;
	}

That way I can always tell when I read again the code wether this was 
intentional or not. It wouldn't hurt at all if that "fallthrough" 
comment became a keyword:

	switch (c) {
		case 1:
			blah();
			break;
		case 2:
			blah();
			fallthrough;
		case 3:
			blah();
			break;
	}

Now the intent is clear even for the compiler.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Nov 15 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michel Fortin wrote:

 Hum two suggestions. Sometime I want fall-through when I write a switch, 
 but I always make it clear that it isn't a bug by writing the intent in 
 a short comment:
 
     switch (c) {
         case 1:
             blah();
             break;
         case 2:
             blah();
             // fallthrough
         case 3:
             blah();
             break;
     }


I just use whitespace:

      switch (c) {
          case 1:
              blah();
              break;

          case 2:
              blah();
          case 3:
              blah();
              break;
      }

Works fine.
Nov 15 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:


 I just use whitespace:
 
       switch (c) {
           case 1:
               blah();
               break;
 
           case 2:
               blah();
           case 3:
               blah();
               break;
       }
 
 Works fine.


If that's a try at something humorous I don't get it.

Bye,
bearophile
Nov 15 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 Michel Fortin wrote:

 Hum two suggestions. Sometime I want fall-through when I write a 
 switch, but I always make it clear that it isn't a bug by writing the 
 intent in a short comment:

     switch (c) {
         case 1:
             blah();
             break;
         case 2:
             blah();
             // fallthrough
         case 3:
             blah();
             break;
     }


 
 I just use whitespace:
 
      switch (c) {
          case 1:
              blah();
              break;
 
          case 2:
              blah();
          case 3:
              blah();
              break;
      }
 
 Works fine.


No whitespace works fine, too. I strongly advise requiring control flow 
at the end of the break. Your style notwithstanding, fall through *is* 
rare. It is also more brittle than goto case xxx; because it is not 
invariant to manual code motion. It does make sense to write more to 
achieve the more dangerous and less used result, than the other way around.

Andrei
Nov 15 2009
prev sibling next sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Andrei Alexandrescu wrote:

 
 Walter's answer to that has put me to silence for good. "But I use
 fall-through all the time!" I then knew the feature will never make it.
 


T_T

There has to be a better way to do fall-through.

Maybe...

switch(foo)
{
    case 0;
    case 1; bar = baz; // Executed if foo == 0
    case 2:
        doSomething(bar); // Executed for foo ∈ {0,1,2}
        break; //required for compile success.
}
Nov 15 2009
parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Chad J wrote:

 
 There has to be a better way to do fall-through.
 
 Maybe...
 
 switch(foo)
 {
     case 0;
     case 1; bar = baz; // Executed if foo == 0
     case 2:
         doSomething(bar); // Executed for foo ∈ {0,1,2}
         break; //required for compile success.
 }


or if you want it to look nicer, maybe introduce an arrow token:

switch(foo)
{
    case 0 ->
    case 1 -> bar = baz; // Executed if foo == 0
    case 2:
        doSomething(bar); // Executed for foo ∈ {0,1,2}
        break; //required for compile success.
}

It has these advantages:
* Fall-through behavior is explicit.
* Fall-through notation requires no extra lines of source, and only a
couple extra columns.

Sigh, I didn't want to discuss syntax, but that response... it makes me
want to solve problems, to say the least.
Nov 15 2009
prev sibling next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Andrei Alexandrescu wrote:

 Chad J wrote:

 So, switch-case statements are a frequent source of nasty bugs.  Fixing
 them (well) requires breaking backwards compatibility.

 Any chance this will happen for D2?

 (This is intended as more of a reminder and simple curiosity than a
 discussion.)


 
 I wish very much that a transferring control flow statement (break, 
 return, goto etc.) is required at the end of each case. Then, the rare 
 case when you want to break through is easy to implement as goto case 
 xxx; and all is good.
 
 Walter's answer to that has put me to silence for good. "But I use 
 fall-through all the time!" I then knew the feature will never make it.
 
 
 Andrei


For what its worth, in a (very domain specific) scripting language I've been
working on, I 
used 'continue' to implement fall-through, and haven't felt too bad about it. 
That and 
being able to do (case A, B, C:) helps for the most common (IME) sort of use.

//////////////////////////////////////////////////
.__receive system ( cmd: STR,  params )
     switch ( cmd .lowercase .tosym )
         case 'lo', 'login':
             user.tell( "(LOgin has been deprecated; please start using COnnect
instead.)")
             continue;

         case 'co', 'connect':
             uname, pwd <- params;
             who = #Database::User.lookup( uname )
             if ( who.valid && who.accept_password( pwd ) )
		return .accept( user, who );
             end

         // ... and so on ...
     end
end
//////////////////////////////////////////////////

-- Chris Nicholson-Sauls
Nov 15 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Chris Nicholson-Sauls wrote:

 For what its worth, in a (very domain specific) scripting language I've 
 been working on, I used 'continue' to implement fall-through, and 
 haven't felt too bad about it.


Using "continue" for that purpose would silently break a lot of existing 
code.
Nov 15 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:

 Chad J wrote:

 So, switch-case statements are a frequent source of nasty bugs.  Fixing
 them (well) requires breaking backwards compatibility.

 Any chance this will happen for D2?

 (This is intended as more of a reminder and simple curiosity than a
 discussion.)


 
 I wish very much that a transferring control flow statement (break, 
 return, goto etc.) is required at the end of each case. Then, the rare 
 case when you want to break through is easy to implement as goto case 
 xxx; and all is good.
 
 Walter's answer to that has put me to silence for good. "But I use 
 fall-through all the time!" I then knew the feature will never make it.


Walter definitely *thinks* he uses fall-through all of the time. BUT...
Does he *really* use it all the time? It's not a matter of opinion; it's 
an objective question, answerable since so much of his code is now 
publically available. I got a bit interested in knowing how much he does 
use it.

I consider that fallthrough requires a non-empty statement. IE,
case A:
case B:
case C:
      dosomething();
      break;

is not a real fallthrough; those would always be allowed.

I looked through a couple of DMD files: parse.c, (the parser), and 
cod3.c (the largest file in the back-end).
In cod3, there are 381 case statements. There are 3 occasions where 
fallthrough is used. In two of those cases, they fallthrough to a label 
where other cases have 'goto' that label. In the remaining case, the 
code which was fallen through was an assert and a debug print statement.

parse.c has 541 case statements, I didn't find any fallthroughs in the 
first half of the code, but I didn't look as thoroughly as I did in cod3.

Based on this, it looks to me as though Walter uses fall-through very, 
very rarely. Less than 1% of all case statements.
For comparison, those files contain 178 and 137 gotos, respectively <g>.
Walter does use 'goto'. He doesn't use fallthrough in switch statements.

It's actually not something I care about at all. But I think Walter's 
wrong about his coding style. And looking at how rarely it's actually 
used by someone who thinks he uses it a lot, convinces me that 
intentional use of fall-through is much less common than bugs introduced 
by leaving out a break statement.

An interesting result.
But I'd much rather change Walter's mind about opPow() or the 
meta.compiles(XXX) proposal.
Nov 15 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:

 And looking at how rarely it's actually 
 used by someone who thinks he uses it a lot, convinces me that 
 intentional use of fall-through is much less common than bugs introduced 
 by leaving out a break statement.


Except that I cannot recall ever having a bug from leaving out a break <g>.
Nov 15 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:


 Except that I cannot recall ever having a bug from leaving out a break <g>.


Even if that's true, fall-through bugs are well know, documented even.

Bye,
bearophile
Nov 15 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 Walter Bright:
 

 Except that I cannot recall ever having a bug from leaving out a break <g>.


 
 Even if that's true, fall-through bugs are well know, documented even.
 
 Bye,
 bearophile


Link?

Andrei
Nov 15 2009
parent reply bearophile writes:
Andrei Alexandrescu


 Link?


If you do a search with Google with:
switch bug "missing break"
Or:
switch bug "fall through"
Or:
switch most common programming bugs

You will see a ton of pages.
Wikipedia says this is a common bug:
http://en.wikipedia.org/wiki/Switch_statement
A bug in Python:
http://bugs.python.org/issue4772
Gcj:
http://gcc.gnu.org/ml/java/2001-12/msg00153.html
Page on C++ pitfalls:
http://www.gauravcreations.com/tutorials/c_pitfalls.html
It's error 825 on Gimpel:
http://www.gimpel.com/html/pub90/msg.txt
Ona page of common C bugs:

Another in Gcc:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31137
More:
http://pear.php.net/bugs/bug.php?id=5020
http://sourceware.org/ml/gdb-patches/2006-04/msg00234.html
https://savannah.cern.ch/bugs/?15576
http://aspn.activestate.com/ASPN/Mail/Message/php-Dev/901756
http://opensource.atlassian.com/projects/hibernate/browse/HHH-448
A page that warns again them:
http://www.jaggersoft.com/pubs/CVu09_1.html
Listed by Linus:
http://lkml.org/lkml/2005/9/30/219
Java findbugs is supposed to find them:
http://osdir.com/ml/java.findbugs.general/2005-01/msg00020.html
In boost:
http://www.boost.org/doc/tools/jam/jam/history.html

If you keep searching you can find a good amount of them.
It's not the most common kind of bug, but it seems common enough to deserve
warnings, lints, several pages of "C/C++ traps & tricks", etc.

There is also a well know bug by AT&T, but it's a little different:
http://www.gowrikumar.com/blog/2009/01/06/att-break-bug/

Bye,
bearophile
Nov 15 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 A bug in Python:
 http://bugs.python.org/issue4772


That is the only one I checked, and it was not a case fall-through bug. 
It was failure to provide a default.
Nov 15 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:


 That is the only one I checked, and it was not a case fall-through bug. 
 It was failure to provide a default.


Sorry...
Most of those bugs seem about the missing break, but indeed it seems that the
missing default is an even more common bug, that's why I have said "It's not
the most common bug".

Bye,
bearophile
Nov 15 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 Don wrote:

 And looking at how rarely it's actually used by someone who thinks he 
 uses it a lot, convinces me that intentional use of fall-through is 
 much less common than bugs introduced by leaving out a break statement.


 
 Except that I cannot recall ever having a bug from leaving out a break <g>.


I can. I'm not sure where that leaves us. Others - please add your 
experience.

Andrei
Nov 15 2009
next sibling parent Derek Parnell <derek psych.ward> writes:
On Sun, 15 Nov 2009 15:03:39 -0600, Andrei Alexandrescu wrote:



 I'm not sure where that leaves us. Others - please add your 
 experience.


Once Euphoria had implemented the 'fallthru' statement, it was like a
weight lifted from the code. It just looked better and was far easier to
write code. A small change, but an wonderfully liberating change. A bit
like the effect of using [$] rather than [length].

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Nov 15 2009
prev sibling next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Andrei Alexandrescu wrote:

 Walter Bright wrote:

 Don wrote:

 And looking at how rarely it's actually used by someone who thinks he
 uses it a lot, convinces me that intentional use of fall-through is
 much less common than bugs introduced by leaving out a break statement.


 Except that I cannot recall ever having a bug from leaving out a break
 <g>.


 
 I can. I'm not sure where that leaves us. Others - please add your
 experience.
 
 Andrei


Just did a quick scan of phobos1. Found 5 instances of fallthrough, not
including one around line 182, format.d

    case Mangle.Tdchar:
      ti = typeid(dchar);
    default:
      ti = null;

I have a hard time believing that was intentional, although it as near
as I can tell it will never be executed.

"Written by Walter Bright"

hm.
Nov 15 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ellery Newcomer wrote:

 Just did a quick scan of phobos1. Found 5 instances of fallthrough, not
 including one around line 182, format.d
 
     case Mangle.Tdchar:
       ti = typeid(dchar);
     default:
       ti = null;
 
 I have a hard time believing that was intentional, although it as near
 as I can tell it will never be executed.
 
 "Written by Walter Bright"
 
 hm.
 


LOL! Looks like you got me there. It appears here: 
http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/format.d?rev=132
in the first version of that switch statement.

I'll check in a fix.

Lesson learned: Never open source your software! <g>
Nov 15 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 15 de noviembre a las 18:10 me escribiste:

 Ellery Newcomer wrote:

Just did a quick scan of phobos1. Found 5 instances of fallthrough, not
including one around line 182, format.d

    case Mangle.Tdchar:
      ti = typeid(dchar);
    default:
      ti = null;

I have a hard time believing that was intentional, although it as near
as I can tell it will never be executed.

"Written by Walter Bright"

hm.


 
 LOL! Looks like you got me there. It appears here:
http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/format.d?rev=132
 in the first version of that switch statement.
 
 I'll check in a fix.
 
 Lesson learned: Never open source your software! <g>


Yes, you might get a good quality software when doing that, who wants
that!? =)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
I am so psychosomatic it makes me sick just thinking about it!
	-- George Constanza
Nov 15 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 Ellery Newcomer wrote:

 Just did a quick scan of phobos1. Found 5 instances of fallthrough, not
 including one around line 182, format.d

     case Mangle.Tdchar:
       ti = typeid(dchar);
     default:
       ti = null;

 I have a hard time believing that was intentional, although it as near
 as I can tell it will never be executed.

 "Written by Walter Bright"

 hm.


 
 LOL! Looks like you got me there. It appears here: 
 http://www.dsource.org/projects/phobos/browser/trunk/phobos/
td/format.d?rev=132 
 
 in the first version of that switch statement.
 
 I'll check in a fix.
 
 Lesson learned: Never open source your software! <g>


I was hoping the lesson learned would be to fix switch as was suggested.

Andrei
Nov 16 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 I was hoping the lesson learned would be to fix switch as was suggested.


I checked, because it wasn't written in the way I usually write things, 
and sure enough it wasn't code I wrote :-)

 From the changelog for D 0.129: "Incorporated Ben Hinkle's new 
std.format which can print general arrays."

http://www.digitalmars.com/d/1.0/changelog1.html#new0129
Nov 16 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 Andrei Alexandrescu wrote:

 I was hoping the lesson learned would be to fix switch as was suggested.


 
 I checked, because it wasn't written in the way I usually write things, 
 and sure enough it wasn't code I wrote :-)
 
  From the changelog for D 0.129: "Incorporated Ben Hinkle's new 
 std.format which can print general arrays."
 
 http://www.digitalmars.com/d/1.0/changelog1.html#new0129


So people are liable to make the mistake.

Andrei
Nov 16 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, Nov 16, 2009 at 8:24 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Walter Bright wrote:

 Andrei Alexandrescu wrote:

 I was hoping the lesson learned would be to fix switch as was suggested=






.

 I checked, because it wasn't written in the way I usually write things,
 and sure enough it wasn't code I wrote :-)

 =A0From the changelog for D 0.129: "Incorporated Ben Hinkle's new std.fo=




rmat

 which can print general arrays."

 http://www.digitalmars.com/d/1.0/changelog1.html#new0129


 So people are liable to make the mistake.

 Andrei


What about when you want to fall through to a multiple label?  Or a range l=
abel?

case 0:
    // do stuff
    goto case ??;
case 1: .. case 9:
     // do more stuff
     goto case ??;
case 10,20,30:
     // still more stuff

The obvious answer would seem to be just "pick any one".
I just bring it up because I haven't seen that ... uh case ...
mentioned by anyone.

--bb
Nov 16 2009
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Nov 17, 09 01:12, Bill Baxter wrote:

 On Mon, Nov 16, 2009 at 8:24 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org>  wrote:

 Walter Bright wrote:

 Andrei Alexandrescu wrote:

 I was hoping the lesson learned would be to fix switch as was suggested.


 I checked, because it wasn't written in the way I usually write things,
 and sure enough it wasn't code I wrote :-)

   From the changelog for D 0.129: "Incorporated Ben Hinkle's new std.format
 which can print general arrays."

 http://www.digitalmars.com/d/1.0/changelog1.html#new0129


 So people are liable to make the mistake.

 Andrei


 What about when you want to fall through to a multiple label?  Or a range
label?

 case 0:
      // do stuff
      goto case ??;
 case 1: .. case 9:
       // do more stuff
       goto case ??;
 case 10,20,30:
       // still more stuff

 The obvious answer would seem to be just "pick any one".
 I just bring it up because I haven't seen that ... uh case ...
 mentioned by anyone.

 --bb


Since

case a:
..
case b:

expands to

case a:
case a+1:
case a+2:
// ....
case b:

and

case a,b,c,d:

expands to

case a:
case b:
case c:
case d:

Your speculation is correct. Please note that the "goto case X;" 
statement works *now*, so there's no need to guess its behavior.
Nov 16 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, Nov 16, 2009 at 9:30 AM, KennyTM~ <kennytm gmail.com> wrote:

 On Nov 17, 09 01:12, Bill Baxter wrote:

 On Mon, Nov 16, 2009 at 8:24 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> =A0wrote:

 Walter Bright wrote:

 Andrei Alexandrescu wrote:

 I was hoping the lesson learned would be to fix switch as was
 suggested.


 I checked, because it wasn't written in the way I usually write things=








,

 and sure enough it wasn't code I wrote :-)

 =A0From the changelog for D 0.129: "Incorporated Ben Hinkle's new
 std.format
 which can print general arrays."

 http://www.digitalmars.com/d/1.0/changelog1.html#new0129


 So people are liable to make the mistake.

 Andrei


 What about when you want to fall through to a multiple label? =A0Or a ra=




nge

 label?

 case 0:
 =A0 =A0 // do stuff
 =A0 =A0 goto case ??;
 case 1: .. case 9:
 =A0 =A0 =A0// do more stuff
 =A0 =A0 =A0goto case ??;
 case 10,20,30:
 =A0 =A0 =A0// still more stuff

 The obvious answer would seem to be just "pick any one".
 I just bring it up because I haven't seen that ... uh case ...
 mentioned by anyone.

 --bb


 Since

 case a:
 ..
 case b:

 expands to

 case a:
 case a+1:
 case a+2:
 // ....
 case b:

 and

 case a,b,c,d:

 expands to

 case a:
 case b:
 case c:
 case d:

 Your speculation is correct. Please note that the "goto case X;" statemen=


t

 works *now*, so there's no need to guess its behavior.


Seriously?  Didn't realize.

So valid end-of-case statements would be:
   break;
   return;
   continue;
   goto *;
   goto case *;
And if you don't have one of those then it's an error?

Could this get into difficult-to-verify territory?  And therefore be
difficult to implement?
It looks like the exact same problem as enforcing that all code paths
return a value, which is something I think D doesn't currently enforce
because it's too hard.   So you run into Walter's dislike for
errors/warnings that are incorrect because the compiler is too stupid.


--bb
Nov 16 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:


 Could this get into difficult-to-verify territory?  And therefore be
 difficult to implement?
 It looks like the exact same problem as enforcing that all code paths
 return a value, which is something I think D doesn't currently enforce
 because it's too hard.   So you run into Walter's dislike for
 errors/warnings that are incorrect because the compiler is too stupid.


If someone writes a switch case so complex that the compiler isn't able to
understand if it's a fall-through or not, then that's a sign that the code
needs to be improved/simplified :-)

Bye,
bearophile
Nov 16 2009
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Nov 17, 09 01:48, Bill Baxter wrote:

 On Mon, Nov 16, 2009 at 9:30 AM, KennyTM~<kennytm gmail.com>  wrote:

 On Nov 17, 09 01:12, Bill Baxter wrote:

 On Mon, Nov 16, 2009 at 8:24 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org>    wrote:

 Walter Bright wrote:

 Andrei Alexandrescu wrote:

 I was hoping the lesson learned would be to fix switch as was
 suggested.


 I checked, because it wasn't written in the way I usually write things,
 and sure enough it wasn't code I wrote :-)

   From the changelog for D 0.129: "Incorporated Ben Hinkle's new
 std.format
 which can print general arrays."

 http://www.digitalmars.com/d/1.0/changelog1.html#new0129


 So people are liable to make the mistake.

 Andrei


 What about when you want to fall through to a multiple label?  Or a range
 label?

 case 0:
      // do stuff
      goto case ??;
 case 1: .. case 9:
       // do more stuff
       goto case ??;
 case 10,20,30:
       // still more stuff

 The obvious answer would seem to be just "pick any one".
 I just bring it up because I haven't seen that ... uh case ...
 mentioned by anyone.

 --bb


 Since

 case a:
 ..
 case b:

 expands to

 case a:
 case a+1:
 case a+2:
 // ....
 case b:

 and

 case a,b,c,d:

 expands to

 case a:
 case b:
 case c:
 case d:

 Your speculation is correct. Please note that the "goto case X;" statement
 works *now*, so there's no need to guess its behavior.


 Seriously?  Didn't realize.

 So valid end-of-case statements would be:
     break;
     return;
     continue;
     goto *;
     goto case *;


throw ...;
assert(...);


 And if you don't have one of those then it's an error?

 Could this get into difficult-to-verify territory?  And therefore be
 difficult to implement?
 It looks like the exact same problem as enforcing that all code paths
 return a value, which is something I think D doesn't currently enforce
 because it's too hard.   So you run into Walter's dislike for
 errors/warnings that are incorrect because the compiler is too stupid.


 --bb


But DMD already has the "no return at end of function" warning.
Nov 16 2009
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
KennyTM~ wrote:

 On Nov 17, 09 01:48, Bill Baxter wrote:

 On Mon, Nov 16, 2009 at 9:30 AM, KennyTM~<kennytm gmail.com>  wrote:

 On Nov 17, 09 01:12, Bill Baxter wrote:

 On Mon, Nov 16, 2009 at 8:24 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org>    wrote:

 Walter Bright wrote:

 Andrei Alexandrescu wrote:

 I was hoping the lesson learned would be to fix switch as was
 suggested.


 I checked, because it wasn't written in the way I usually write
 things,
 and sure enough it wasn't code I wrote :-)

   From the changelog for D 0.129: "Incorporated Ben Hinkle's new
 std.format
 which can print general arrays."

 http://www.digitalmars.com/d/1.0/changelog1.html#new0129


 So people are liable to make the mistake.

 Andrei


 What about when you want to fall through to a multiple label?  Or a
 range
 label?

 case 0:
      // do stuff
      goto case ??;
 case 1: .. case 9:
       // do more stuff
       goto case ??;
 case 10,20,30:
       // still more stuff

 The obvious answer would seem to be just "pick any one".
 I just bring it up because I haven't seen that ... uh case ...
 mentioned by anyone.

 --bb


 Since

 case a:
 ..
 case b:

 expands to

 case a:
 case a+1:
 case a+2:
 // ....
 case b:

 and

 case a,b,c,d:

 expands to

 case a:
 case b:
 case c:
 case d:

 Your speculation is correct. Please note that the "goto case X;"
 statement
 works *now*, so there's no need to guess its behavior.


 Seriously?  Didn't realize.

 So valid end-of-case statements would be:
     break;
     return;
     continue;
     goto *;
     goto case *;


 
 throw ...;
 assert(...);
 


you can call functions which do these...
Nov 16 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ellery Newcomer wrote:

 KennyTM~ wrote:

 On Nov 17, 09 01:48, Bill Baxter wrote:

 On Mon, Nov 16, 2009 at 9:30 AM, KennyTM~<kennytm gmail.com>  wrote:

 On Nov 17, 09 01:12, Bill Baxter wrote:

 On Mon, Nov 16, 2009 at 8:24 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org>    wrote:

 Walter Bright wrote:

 Andrei Alexandrescu wrote:

 I was hoping the lesson learned would be to fix switch as was
 suggested.


 I checked, because it wasn't written in the way I usually write
 things,
 and sure enough it wasn't code I wrote :-)

   From the changelog for D 0.129: "Incorporated Ben Hinkle's new
 std.format
 which can print general arrays."

 http://www.digitalmars.com/d/1.0/changelog1.html#new0129


 So people are liable to make the mistake.

 Andrei


 What about when you want to fall through to a multiple label?  Or a
 range
 label?

 case 0:
      // do stuff
      goto case ??;
 case 1: .. case 9:
       // do more stuff
       goto case ??;
 case 10,20,30:
       // still more stuff

 The obvious answer would seem to be just "pick any one".
 I just bring it up because I haven't seen that ... uh case ...
 mentioned by anyone.

 --bb


 Since

 case a:
 ..
 case b:

 expands to

 case a:
 case a+1:
 case a+2:
 // ....
 case b:

 and

 case a,b,c,d:

 expands to

 case a:
 case b:
 case c:
 case d:

 Your speculation is correct. Please note that the "goto case X;"
 statement
 works *now*, so there's no need to guess its behavior.


 Seriously?  Didn't realize.

 So valid end-of-case statements would be:
     break;
     return;
     continue;
     goto *;
     goto case *;


 throw ...;
 assert(...);


 
 you can call functions which do these...


... which is where the "none"/"bottom" type comes into play!

Andrei
Nov 16 2009
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Andrei Alexandrescu wrote:

 Ellery Newcomer wrote:

 KennyTM~ wrote:

 throw ...;
 assert(...);


 you can call functions which do these...


 
 ... which is where the "none"/"bottom" type comes into play!
 
 Andrei


What what?
Nov 16 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ellery Newcomer wrote:

 Andrei Alexandrescu wrote:

 Ellery Newcomer wrote:

 KennyTM~ wrote:

 throw ...;
 assert(...);


 you can call functions which do these...


 ... which is where the "none"/"bottom" type comes into play!

 Andrei


 
 What what?


http://en.wikipedia.org/wiki/Bottom_type
http://www.cs.washington.edu/research/projects/cecil/www/Release/doc-cecil-stdlib/node4.html

I gave a talk about similar stuff once but I don't know where it is. I 
also have 70% of an article on it written (and with a funny introduction 
to boot) but I couldn't find the time * interest to finish.


Andrei
Nov 16 2009
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Andrei Alexandrescu wrote:

 Ellery Newcomer wrote:

 Andrei Alexandrescu wrote:

 Ellery Newcomer wrote:

 KennyTM~ wrote:

 throw ...;
 assert(...);


 you can call functions which do these...


 ... which is where the "none"/"bottom" type comes into play!

 Andrei


 What what?


 
 http://en.wikipedia.org/wiki/Bottom_type
 http://www.cs.washington.edu/research/projects/cecil/www/Release/doc-cecil-stdlib/node4.html
 
 
 I gave a talk about similar stuff once but I don't know where it is. I
 also have 70% of an article on it written (and with a funny introduction
 to boot) but I couldn't find the time * interest to finish.
 
 
 Andrei


So a function that always throws should have a result type (maximal
type?) of bottom type?
Nov 16 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ellery Newcomer wrote:

 Andrei Alexandrescu wrote:

 Ellery Newcomer wrote:

 Andrei Alexandrescu wrote:

 Ellery Newcomer wrote:

 KennyTM~ wrote:

 throw ...;
 assert(...);


 you can call functions which do these...


 ... which is where the "none"/"bottom" type comes into play!

 Andrei


 What what?


 http://en.wikipedia.org/wiki/Bottom_type
 http://www.cs.washington.edu/research/projects/cecil/www/Release/doc-cecil-stdlib/node4.html


 I gave a talk about similar stuff once but I don't know where it is. I
 also have 70% of an article on it written (and with a funny introduction
 to boot) but I couldn't find the time * interest to finish.


 Andrei


 
 So a function that always throws should have a result type (maximal
 type?) of bottom type?


Yah, because it never actually returns. Functions like abort() or exit() 
would return bottom in a type system that supports it.

Andrei
Nov 16 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Mon, Nov 16, 2009 at 9:30 AM, KennyTM~ <kennytm gmail.com> wrote:

 On Nov 17, 09 01:12, Bill Baxter wrote:

 On Mon, Nov 16, 2009 at 8:24 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org>  wrote:

 Walter Bright wrote:

 Andrei Alexandrescu wrote:

 I was hoping the lesson learned would be to fix switch as was
 suggested.


 I checked, because it wasn't written in the way I usually write things,
 and sure enough it wasn't code I wrote :-)

  From the changelog for D 0.129: "Incorporated Ben Hinkle's new
 std.format
 which can print general arrays."

 http://www.digitalmars.com/d/1.0/changelog1.html#new0129


 So people are liable to make the mistake.

 Andrei


 What about when you want to fall through to a multiple label?  Or a range
 label?

 case 0:
     // do stuff
     goto case ??;
 case 1: .. case 9:
      // do more stuff
      goto case ??;
 case 10,20,30:
      // still more stuff

 The obvious answer would seem to be just "pick any one".
 I just bring it up because I haven't seen that ... uh case ...
 mentioned by anyone.

 --bb


 Since

 case a:
 ..
 case b:

 expands to

 case a:
 case a+1:
 case a+2:
 // ....
 case b:

 and

 case a,b,c,d:

 expands to

 case a:
 case b:
 case c:
 case d:

 Your speculation is correct. Please note that the "goto case X;" statement
 works *now*, so there's no need to guess its behavior.


 
 Seriously?  Didn't realize.
 
 So valid end-of-case statements would be:
    break;
    return;
    continue;
    goto *;
    goto case *;
 And if you don't have one of those then it's an error?


throw *;



 Could this get into difficult-to-verify territory?  And therefore be
 difficult to implement?
 It looks like the exact same problem as enforcing that all code paths
 return a value, which is something I think D doesn't currently enforce
 because it's too hard.   So you run into Walter's dislike for
 errors/warnings that are incorrect because the compiler is too stupid.


It could enter difficult territory if the rule was:

if (condition) break;

and leave it to the compiler to prove that condition is always true. 
That's not the case with the proposed change. All control flow 
statements you enumerated above transfer flow unconditionally.


Andrei
Nov 16 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Mon, Nov 16, 2009 at 8:24 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Walter Bright wrote:

 Andrei Alexandrescu wrote:

 I was hoping the lesson learned would be to fix switch as was suggested.


 I checked, because it wasn't written in the way I usually write things,
 and sure enough it wasn't code I wrote :-)

  From the changelog for D 0.129: "Incorporated Ben Hinkle's new std.format
 which can print general arrays."

 http://www.digitalmars.com/d/1.0/changelog1.html#new0129


 So people are liable to make the mistake.

 Andrei


 
 What about when you want to fall through to a multiple label?  Or a range
label?
 
 case 0:
     // do stuff
     goto case ??;
 case 1: .. case 9:
      // do more stuff
      goto case ??;
 case 10,20,30:
      // still more stuff
 
 The obvious answer would seem to be just "pick any one".
 I just bring it up because I haven't seen that ... uh case ...
 mentioned by anyone.
 
 --bb


You must pick the median :o).

Andrei
Nov 16 2009
parent reply KennyTM~ <kennytm gmail.com> writes:
On Nov 17, 09 01:40, Andrei Alexandrescu wrote:

 Bill Baxter wrote:

 On Mon, Nov 16, 2009 at 8:24 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Walter Bright wrote:

 Andrei Alexandrescu wrote:

 I was hoping the lesson learned would be to fix switch as was
 suggested.


 I checked, because it wasn't written in the way I usually write things,
 and sure enough it wasn't code I wrote :-)

 From the changelog for D 0.129: "Incorporated Ben Hinkle's new
 std.format
 which can print general arrays."

 http://www.digitalmars.com/d/1.0/changelog1.html#new0129


 So people are liable to make the mistake.

 Andrei


 What about when you want to fall through to a multiple label? Or a
 range label?

 case 0:
 // do stuff
 goto case ??;
 case 1: .. case 9:
 // do more stuff
 goto case ??;
 case 10,20,30:
 // still more stuff

 The obvious answer would seem to be just "pick any one".
 I just bring it up because I haven't seen that ... uh case ...
 mentioned by anyone.

 --bb


 You must pick the median :o).

 Andrei


No way we'll need to write "goto case 3.5;" :p
Nov 16 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:

 On Nov 17, 09 01:40, Andrei Alexandrescu wrote:

 Bill Baxter wrote:

 On Mon, Nov 16, 2009 at 8:24 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Walter Bright wrote:

 Andrei Alexandrescu wrote:

 I was hoping the lesson learned would be to fix switch as was
 suggested.


 I checked, because it wasn't written in the way I usually write 
 things,
 and sure enough it wasn't code I wrote :-)

 From the changelog for D 0.129: "Incorporated Ben Hinkle's new
 std.format
 which can print general arrays."

 http://www.digitalmars.com/d/1.0/changelog1.html#new0129


 So people are liable to make the mistake.

 Andrei


 What about when you want to fall through to a multiple label? Or a
 range label?

 case 0:
 // do stuff
 goto case ??;
 case 1: .. case 9:
 // do more stuff
 goto case ??;
 case 10,20,30:
 // still more stuff

 The obvious answer would seem to be just "pick any one".
 I just bring it up because I haven't seen that ... uh case ...
 mentioned by anyone.

 --bb


 You must pick the median :o).

 Andrei


 
 No way we'll need to write "goto case 3.5;" :p


(Just for precision's sake)

median != average

Andrei
Nov 16 2009
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 16 Nov 2009 13:37:52 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 KennyTM~ wrote:

 On Nov 17, 09 01:40, Andrei Alexandrescu wrote:

 You must pick the median :o).

 Andrei


  No way we'll need to write "goto case 3.5;" :p


 (Just for precision's sake)

 median != average


You're mean!

-Steve
Nov 16 2009
prev sibling parent KennyTM~ <kennytm gmail.com> writes:
On Nov 17, 09 02:37, Andrei Alexandrescu wrote:

 KennyTM~ wrote:

 On Nov 17, 09 01:40, Andrei Alexandrescu wrote:

 Bill Baxter wrote:

 On Mon, Nov 16, 2009 at 8:24 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Walter Bright wrote:

 Andrei Alexandrescu wrote:

 I was hoping the lesson learned would be to fix switch as was
 suggested.


 I checked, because it wasn't written in the way I usually write
 things,
 and sure enough it wasn't code I wrote :-)

 From the changelog for D 0.129: "Incorporated Ben Hinkle's new
 std.format
 which can print general arrays."

 http://www.digitalmars.com/d/1.0/changelog1.html#new0129


 So people are liable to make the mistake.

 Andrei


 What about when you want to fall through to a multiple label? Or a
 range label?

 case 0:
 // do stuff
 goto case ??;
 case 1: .. case 9:
 // do more stuff
 goto case ??;
 case 10,20,30:
 // still more stuff

 The obvious answer would seem to be just "pick any one".
 I just bring it up because I haven't seen that ... uh case ...
 mentioned by anyone.

 --bb


 You must pick the median :o).

 Andrei


 No way we'll need to write "goto case 3.5;" :p


 (Just for precision's sake)

 median != average

 Andrei


The median of [1,3,4,10000] is 3.5.
Nov 16 2009
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-11-15 16:03:39 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 Walter Bright wrote:

 Don wrote:

 And looking at how rarely it's actually used by someone who thinks he 
 uses it a lot, convinces me that intentional use of fall-through is 
 much less common than bugs introduced by leaving out a break statement.


 
 Except that I cannot recall ever having a bug from leaving out a break <g>.


 
 I can. I'm not sure where that leaves us. Others - please add your experience.


I did not get my habit of adding a "// fallthrough" comment because 
someone told me I should. It was after experiencing too many "forgotten 
break" bugs that I began to do this so that now if I read some of my 
code that doesn't explicitly mention it wants falltrhough, it looks 
immeditately suspicious. Thus, it helps detecting bugs earlier.

Apparently, Walter's whitespace convention accomplish the same goal. I 
wonder from where it comes...

Most of those missing break bugs I catch early when debugging or 
reviewing, but that is still needlessly time-consuming considering it'd 
be pretty simple for the compiler to make sure everything is all right.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Nov 15 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Sun, Nov 15, 2009 at 1:03 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Walter Bright wrote:

 Don wrote:

 And looking at how rarely it's actually used by someone who thinks he
 uses it a lot, convinces me that intentional use of fall-through is much
 less common than bugs introduced by leaving out a break statement.


 Except that I cannot recall ever having a bug from leaving out a break
 <g>.


 I can. I'm not sure where that leaves us. Others - please add your
 experience.


I have without a doubt forgotten a "break".  Many times.  Last one was
probably just a week or two ago.  Of course now after years of C and
C++, I'm more attuned to it, so it didn't take that long to figure out
where the bug is.  But still it's annoying.

--bb
Nov 15 2009
prev sibling parent Max Samukha <spambox d-coding.com> writes:
On Sun, 15 Nov 2009 15:03:39 -0600, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:


Walter Bright wrote:

 Don wrote:

 And looking at how rarely it's actually used by someone who thinks he 
 uses it a lot, convinces me that intentional use of fall-through is 
 much less common than bugs introduced by leaving out a break statement.


 
 Except that I cannot recall ever having a bug from leaving out a break <g>.


I can. I'm not sure where that leaves us. Others - please add your 
experience.

Andrei


I used to introduce bugs by leaving out 'break'. So I had to fall into
habit of writing 'break' before adding other code to a case block.
Fall-through should be explicit.
Nov 16 2009
prev sibling next sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Walter Bright wrote:

 Don wrote:

 And looking at how rarely it's actually used by someone who thinks he
 uses it a lot, convinces me that intentional use of fall-through is
 much less common than bugs introduced by leaving out a break statement.


 
 Except that I cannot recall ever having a bug from leaving out a break <g>.


That's because you're a cyborg.

Have some pity on us mere mortals ;)
Nov 15 2009
parent Bill Baxter <wbaxter gmail.com> writes:
On Sun, Nov 15, 2009 at 1:16 PM, Chad J
<chadjoan __spam.is.bad__gmail.com> wrote:

 Walter Bright wrote:

 Don wrote:

 And looking at how rarely it's actually used by someone who thinks he
 uses it a lot, convinces me that intentional use of fall-through is
 much less common than bugs introduced by leaving out a break statement.


 Except that I cannot recall ever having a bug from leaving out a break <g>.


 That's because you're a cyborg.

 Have some pity on us mere mortals ;)


Yeh, you have to wondoer, is the goal to write a language that's
perfect for yourself or perfect for the widest audience possible?

--bb
Nov 15 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 15 de noviembre a las 12:13 me escribiste:

 Don wrote:

And looking at how rarely it's actually used by someone who thinks
he uses it a lot, convinces me that intentional use of
fall-through is much less common than bugs introduced by leaving
out a break statement.


 
 Except that I cannot recall ever having a bug from leaving out a break <g>.


A lot of people do.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Yo soy peperino el que siempre pone el vino, yo soy aquel que come los
huevos con tocino.
	-- Peperino Pómoro
Nov 15 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Don:


 I consider that fallthrough requires a non-empty statement. IE,
 case A:
 case B:
 case C:
       dosomething();
       break;
 
 is not a real fallthrough; those would always be allowed.


In D this is the right way to write that:

case A, B, C:
    dosomething();
    break;

Bye,
bearophile
Nov 15 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:

 Andrei Alexandrescu wrote:

 Chad J wrote:

 So, switch-case statements are a frequent source of nasty bugs.  Fixing
 them (well) requires breaking backwards compatibility.

 Any chance this will happen for D2?

 (This is intended as more of a reminder and simple curiosity than a
 discussion.)


 I wish very much that a transferring control flow statement (break, 
 return, goto etc.) is required at the end of each case. Then, the rare 
 case when you want to break through is easy to implement as goto case 
 xxx; and all is good.

 Walter's answer to that has put me to silence for good. "But I use 
 fall-through all the time!" I then knew the feature will never make it.


 
 Walter definitely *thinks* he uses fall-through all of the time. BUT...
 Does he *really* use it all the time? It's not a matter of opinion; it's 
 an objective question, answerable since so much of his code is now 
 publically available. I got a bit interested in knowing how much he does 
 use it.
 
 I consider that fallthrough requires a non-empty statement. IE,
 case A:
 case B:
 case C:
      dosomething();
      break;
 
 is not a real fallthrough; those would always be allowed.
 
 I looked through a couple of DMD files: parse.c, (the parser), and 
 cod3.c (the largest file in the back-end).
 In cod3, there are 381 case statements. There are 3 occasions where 
 fallthrough is used. In two of those cases, they fallthrough to a label 
 where other cases have 'goto' that label. In the remaining case, the 
 code which was fallen through was an assert and a debug print statement.
 
 parse.c has 541 case statements, I didn't find any fallthroughs in the 
 first half of the code, but I didn't look as thoroughly as I did in cod3.
 
 Based on this, it looks to me as though Walter uses fall-through very, 
 very rarely. Less than 1% of all case statements.
 For comparison, those files contain 178 and 137 gotos, respectively <g>.
 Walter does use 'goto'. He doesn't use fallthrough in switch statements.
 
 It's actually not something I care about at all. But I think Walter's 
 wrong about his coding style. And looking at how rarely it's actually 
 used by someone who thinks he uses it a lot, convinces me that 
 intentional use of fall-through is much less common than bugs introduced 
 by leaving out a break statement.
 
 An interesting result.
 But I'd much rather change Walter's mind about opPow() or the 
 meta.compiles(XXX) proposal.


Don       <----------        genius

I understand that you're more interested about the issues that preoccupy 
you (and incidentally me) the most, but "switch" is a day-to-day 
programming (and programmer's) workhorse, so a change there might have a 
wider (and hopefully more positive) impact.


Andrei
Nov 15 2009
parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:

 Don wrote:

 Andrei Alexandrescu wrote:

 Chad J wrote:

 So, switch-case statements are a frequent source of nasty bugs.  Fixing
 them (well) requires breaking backwards compatibility.

 Any chance this will happen for D2?

 (This is intended as more of a reminder and simple curiosity than a
 discussion.)



 Walter's answer to that has put me to silence for good. "But I use 
 fall-through all the time!" I then knew the feature will never make it.







 It's actually not something I care about at all. But I think Walter's 
 wrong about his coding style. And looking at how rarely it's actually 
 used by someone who thinks he uses it a lot, convinces me that 
 intentional use of fall-through is much less common than bugs 
 introduced by leaving out a break statement.

 An interesting result.
 But I'd much rather change Walter's mind about opPow() or the 
 meta.compiles(XXX) proposal.


 
 Don       <----------        genius


Nah, I just know how Walter's mind works. It takes one to know one...

I frequently use fall-through myself, but having looked at this sample, 
I bet I don't use it nearly as much as I thought: again, "frequently" 
probably means "about 1% of the time". But I *know* I've had bugs from 
leaving out 'break'.


 I understand that you're more interested about the issues that preoccupy 
 you (and incidentally me) the most, but "switch" is a day-to-day 
 programming (and programmer's) workhorse, so a change there might have a 
 wider (and hopefully more positive) impact.


I should have said "immutable array literals" instead.



 I wish very much that a transferring control flow statement (break,
 return, goto etc.) is required at the end of each case. Then, the
 rare case when you want to break through is easy to implement as goto
 case xxx; and all is good.






Requiring 'goto' to implement fall-through would run into the prejudice 
against 'goto'. It's necessary to persuade managers that "goto case 
XXX;" isn't a bad, evil goto that eats babies. I have no idea if that's 
difficult or not. Otherwise, I think it's a superb solution.
(providing that empty fall-through case statements remain valid; 
disallowing them would be really annoying).
Nov 16 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:

 I frequently use fall-through myself, but having looked at this sample, 
 I bet I don't use it nearly as much as I thought: again, "frequently" 
 probably means "about 1% of the time". But I *know* I've had bugs from 
 leaving out 'break'.


I poked through the optimizer code, gloop.c and gflow.c, and right away 
saw several uses of it.

I used to mark these with /* FALL-THROUGH */, but eventually got tired 
of that (and thought it was ugly) and just switched to using whitespace 
as I mentioned before.
Nov 16 2009
parent reply Don <nospam nospam.com> writes:
Walter Bright wrote:

 Don wrote:

 I frequently use fall-through myself, but having looked at this 
 sample, I bet I don't use it nearly as much as I thought: again, 
 "frequently" probably means "about 1% of the time". But I *know* I've 
 had bugs from leaving out 'break'.


 
 I poked through the optimizer code, gloop.c and gflow.c, and right away 
 saw several uses of it.


You're right, there's one at the top of gloop. And this one in gflow is 
a doozy.


	case OPvptrfptr:
	case OPcvptrfptr:
	    if ((flowxx == AE) && n->Eexp)
		vec_orass(KILL,vptrkill);
	    break;

	default:
	    if (OTunary(op))
	    {
#if TX86
	case OPind:				// most common unary operator
		accumaecpx(n->E1);
#ifdef DEBUG
		assert(!OTassign(op));
#endif
#else
		accumaecpx(n->E1);
		if (OTassign(op))
		    t = Elvalue(n);
#endif
	    }
	    else if (OTbinary(op))
	    {
		if (OTrtol(op) && ERTOL(n))
		{   accumaecpx(n->E2);


That's not fall-through, one case is *inside* the 'if' clause of another 
one!! Wow. Do you really want to encourage that sort of thing?
Nov 16 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Don:


 That's not fall-through, one case is *inside* the 'if' clause of another 
 one!! Wow. Do you really want to encourage that sort of thing?


I don't understand that piece of code, is that valid code? It needs a
reformatting, a rewriting, and then another reformatting.

Bye,
bearophile
Nov 16 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:

 That's not fall-through, one case is *inside* the 'if' clause of another 
 one!! Wow. Do you really want to encourage that sort of thing?


I think it's more the #if that obfuscates the code. After long 
experience with #if, I really don't like it, which is why I adamantly 
resist having fine-grained conditional compilation in D.

The optimizer/code generator has a lot of awful #if's in them, generally 
as a result of it being hackishly ported to other platforms.

I'm not going to stand up and say the optimizer/code gen is a fine 
example of elegant software (it isn't), just that it *works* and is 
remarkably free of bugs.
Nov 16 2009
next sibling parent grauzone <none example.net> writes:
Walter Bright wrote:

 Don wrote:

 That's not fall-through, one case is *inside* the 'if' clause of 
 another one!! Wow. Do you really want to encourage that sort of thing?


 
 I think it's more the #if that obfuscates the code. After long 
 experience with #if, I really don't like it, which is why I adamantly 
 resist having fine-grained conditional compilation in D.


True, but the case label inside the if statement is obfuscation too. I 
bet many C/C++ programmers don't even know that this syntax is allowed...

But we need to keep it for duff's device, I guess.
Nov 16 2009
prev sibling parent Don <nospam nospam.com> writes:
Walter Bright wrote:

 Don wrote:

 That's not fall-through, one case is *inside* the 'if' clause of 
 another one!! Wow. Do you really want to encourage that sort of thing?


 
 I think it's more the #if that obfuscates the code. After long 
 experience with #if, I really don't like it, which is why I adamantly 
 resist having fine-grained conditional compilation in D.


I'm used to that. If you take out the #if, it's still wierd. That one 
really ought to be a goto. It's the presence of the 'else' in particular:

case A:
      if (xxx)
      {
case B:
         yyy;
      }
      else
      {
         zzz;
      }
      break;

I had to read it several times before I could make sense of it. Although 
the zzz; looks like it's part of the B case, it's only part of the A case.

An oddity is that this compiles:

   switch(x) {
case 1:
      if (x<10)
Lcase2:
         writefln("yyy");
      else
         writefln("zzz");
      break;
      }

and so does this:

   switch(x) {
case 1:
      if (x<10)
case 2:
         writefln("yyy");
   }

but this doesn't:

   switch(x) {
case 1:
      if (x<10)
case 2:
         writefln("yyy");
      else
         writefln("zzz");
      break;
   }
Nov 17 2009
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 16 Nov 2009 03:27:22 -0500, Don <nospam nospam.com> wrote:


 Requiring 'goto' to implement fall-through would run into the prejudice  
 against 'goto'. It's necessary to persuade managers that "goto case  
 XXX;" isn't a bad, evil goto that eats babies. I have no idea if that's  
 difficult or not. Otherwise, I think it's a superb solution.
 (providing that empty fall-through case statements remain valid;  
 disallowing them would be really annoying).




http://msdn.microsoft.com/en-us/library/06tc147t(VS.80).aspx

I haven't had any issues with it.  This reminds me of the != null  
problem.  Now if only Walter made as many mistakes with switch case  
fallthrough as he did with != null :)

Walter, at some point, you should heed the complaints of the masses even  
if it doesn't affect you.  It's like a politician who lives in a nice  
neighborhood ignoring the requests of his constituents for more police  
protection in higher crime areas because he doesn't live there.  Except  
it's worse, because we can't vote you out :)

Also keep in mind that this does *not* change the power of switch at all,  
since goto already covers fallthrough.  One thing I learned from the !=  
null to !is null change is that I stopped writing the offending code when  
I get immediate feedback.  It just gets ingrained in my brain better.  So  
having to write goto next_case;  all the time is going to be much less of  
a chore than you think, because you'll just learn to avoid that mistake in  
the first place.

-Steve
Nov 16 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 On Mon, 16 Nov 2009 03:27:22 -0500, Don <nospam nospam.com> wrote:
 

 Requiring 'goto' to implement fall-through would run into the 
 prejudice against 'goto'. It's necessary to persuade managers that 
 "goto case XXX;" isn't a bad, evil goto that eats babies. I have no 
 idea if that's difficult or not. Otherwise, I think it's a superb 
 solution.
 (providing that empty fall-through case statements remain valid; 
 disallowing them would be really annoying).


 

 
 http://msdn.microsoft.com/en-us/library/06tc147t(VS.80).aspx
 
 I haven't had any issues with it.  This reminds me of the != null 
 problem.  Now if only Walter made as many mistakes with switch case 
 fallthrough as he did with != null :)
 
 Walter, at some point, you should heed the complaints of the masses even 
 if it doesn't affect you.  It's like a politician who lives in a nice 
 neighborhood ignoring the requests of his constituents for more police 
 protection in higher crime areas because he doesn't live there.  Except 
 it's worse, because we can't vote you out :)
 
 Also keep in mind that this does *not* change the power of switch at 
 all, since goto already covers fallthrough.  One thing I learned from 
 the != null to !is null change is that I stopped writing the offending 
 code when I get immediate feedback.  It just gets ingrained in my brain 
 better.  So having to write goto next_case;  all the time is going to be 
 much less of a chore than you think, because you'll just learn to avoid 
 that mistake in the first place.


My thoughts exactly. But that being said, if a guy can't design his own 
language to cater for what he thinks he frequently does (massive, 
overwhelming, and exhausting evidence to the contrary notwithstanding), 
then where is freedom in this world?

:o)

Andrei
Nov 16 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 16 Nov 2009 15:01:47 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Steven Schveighoffer wrote:

 On Mon, 16 Nov 2009 03:27:22 -0500, Don <nospam nospam.com> wrote:


 Requiring 'goto' to implement fall-through would run into the  
 prejudice against 'goto'. It's necessary to persuade managers that  
 "goto case XXX;" isn't a bad, evil goto that eats babies. I have no  
 idea if that's difficult or not. Otherwise, I think it's a superb  
 solution.
 (providing that empty fall-through case statements remain valid;  
 disallowing them would be really annoying).



  http://msdn.microsoft.com/en-us/library/06tc147t(VS.80).aspx
  I haven't had any issues with it.  This reminds me of the != null  
 problem.  Now if only Walter made as many mistakes with switch case  
 fallthrough as he did with != null :)
  Walter, at some point, you should heed the complaints of the masses  
 even if it doesn't affect you.  It's like a politician who lives in a  
 nice neighborhood ignoring the requests of his constituents for more  
 police protection in higher crime areas because he doesn't live there.   
 Except it's worse, because we can't vote you out :)
  Also keep in mind that this does *not* change the power of switch at  
 all, since goto already covers fallthrough.  One thing I learned from  
 the != null to !is null change is that I stopped writing the offending  
 code when I get immediate feedback.  It just gets ingrained in my brain  
 better.  So having to write goto next_case;  all the time is going to  
 be much less of a chore than you think, because you'll just learn to  
 avoid that mistake in the first place.


 My thoughts exactly. But that being said, if a guy can't design his own  
 language to cater for what he thinks he frequently does (massive,  
 overwhelming, and exhausting evidence to the contrary notwithstanding),  
 then where is freedom in this world?


You are totally free to make a language that nobody uses :)

-Steve
Nov 16 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:

 You are totally free to make a language that nobody uses :)


About 10 years ago, I went out jogging with a colleague who was also a 
programmer. We were talking about compilers, of course, and he said 
"what the world really needs is a Java compiler that compiles to native 
code, not this VM bull." He assured me that such a product would sweep 
the world.

I told him I thought he was right, and so did a lot of people. So right 
that about 5 years previously, I did just that (for Symantec). Turns 
out, nobody wanted it. I told him I could get him a copy. He didn't want 
it either.

<g>

Another fun story. Back in the 80's, a programmer told a friend that the 
MOST IMPORTANT thing he looked for in a compiler was compilation speed. 
My friend told him that was obviously the least important thing to him. 
Shocked, the programmer asked why? My friend told him that he was using 
the slowest compiler on the market by a factor of 4. There were several 
other much faster C++ compilers available, but he stuck with the slow 
one. The programmer reacted like this thought had never occurred to him.

<g>

More fun stuff. 10 years ago, I was convinced by many people that the 
world needed a fast javascript engine. I built one that was twice as 
fast as Jscript, and twenty (that's right, 20) times faster than 
Mozilla's javascript engine. It passed all the test suites.

I couldn't give it away.


On the other hand, the advice I got when starting to write a C compiler 
was "who the f*** needs another C compiler?" Nobody thought it was a 
good idea. Turns out, there was a big market for it!


Now, I'm not saying you're wrong. I'm just saying that making a product 
that people want isn't as simple as asking them what they want. With the 
switch thing, there's a cost to all the solutions proposed here - rather 
klunky to look at and significant extra work to type them in.

Perhaps the reason I don't have trouble with the usual switch statements 
is because it seems natural to me, as I come from an asm/fortran/basic 
background, where one would never write:

     foo();
     goto L1;
L1: bar();
     goto L2;
L2: baz();
     goto L3;
L3: asdf();
     return;

and case labels look like, well, labels to me. The goto version is ugly 
and hard to read.


Reminds me a bit of D a few years back, when people would say D didn't 
have lambda's. But D did have them! The problem was the syntax was a bit 
verbose. Simplified the syntax, and suddenly the lambda's got noticed 
and got used.
Nov 16 2009
parent reply grauzone <none example.net> writes:
Walter Bright wrote:

 Reminds me a bit of D a few years back, when people would say D didn't 
 have lambda's. But D did have them! The problem was the syntax was a bit 
 verbose. Simplified the syntax, and suddenly the lambda's got noticed 
 and got used.


D has no tuples.
Nov 16 2009
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
grauzone wrote:

 Walter Bright wrote:

 Reminds me a bit of D a few years back, when people would say D didn't 
 have lambda's. But D did have them! The problem was the syntax was a 
 bit verbose. Simplified the syntax, and suddenly the lambda's got 
 noticed and got used.


 
 D has no tuples.


I see what you did there.
Nov 16 2009
prev sibling next sibling parent grauzone <none example.net> writes:
Chad J wrote:

 So, switch-case statements are a frequent source of nasty bugs.  Fixing
 them (well) requires breaking backwards compatibility.
 
 Any chance this will happen for D2?
 
 (This is intended as more of a reminder and simple curiosity than a
 discussion.)


The correct way to solve this is to create a new switch-case statement 
that doesn't suck. It would use a different syntax, and support spiffy 
stuff like pattern matching. If you wanted to use duff's device or need 
C compatibility, you still could use the old switch-case.
Nov 15 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 Walter's answer to that has put me to silence for good. "But I use 
 fall-through all the time!" I then knew the feature will never make it.


We can add a third type of switch to D, that's safer...

Bye,
bearophile
Nov 15 2009
parent reply KennyTM~ <kennytm gmail.com> writes:
On Nov 16, 09 02:36, bearophile wrote:

 Andrei Alexandrescu:


 Walter's answer to that has put me to silence for good. "But I use
 fall-through all the time!" I then knew the feature will never make it.


 We can add a third type of switch to D, that's safer...

 Bye,
 bearophile


 safe switch ? :p
Nov 15 2009
parent bearophile <bearophileHUGS lycos.com> writes:
KennyTM~:


  safe switch ? :p


That's cute. But I was thinking of a safer "caseof" used by default, and the
less safe C switch used only for C compatibility :-) (" unsafe switch" is not
possible because it's against D purposes).

Bye,
bearophile
Nov 15 2009
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Sun, 15 Nov 2009 12:49:01 -0500, Chad J wrote:


 So, switch-case statements are a frequent source of nasty bugs.  Fixing
 them (well) requires breaking backwards compatibility.
 
 Any chance this will happen for D2?


The phrase "snowball in hell" comes to mind.


 (This is intended as more of a reminder and simple curiosity than a
 discussion.)


And in spite of your good intentions (~ not a discussion ~) this will be
one ;-) 

The Euphoria Programming language, which I'm helping to implement, has
'solved' this issue. This language is not a C-derived one so don't be
alarmed at its apparent verbosity.

The default 'case' in a 'switch' is to not fall through; an implied 'break'
is assumed at the end of each 'case' clause. 

  switch Foo do
      case 1 then
         ... whatever for 1 ...
         ... does not fall through to the next case ...

      case 2, 3 then
         ... whatever for 2 and 3 ...
         ... does not fall through to the next case ...

      case 4 then
         ... whatever for 4 ...
         ... does not fall through to the next case ...

  end switch


However, the coder can change the default behaviour on a 'switch' statement
by including the phrase 'with fallthru', thus changing the default
behaviour such that each 'case' clause will fall through to the next case
unless the coder uses an explicit 'break' statement. This, as you can see,
is the DPL behaviour.

  switch Foo with fallthru do
      case 1 then
         ... whatever for 1 ...
         ... falls through to the next case ...

      case 2, 3 then
         ... whatever for 2 and 3 ...
         break   /* explicitly required to prevent falling through */

      case 4 then
         ... whatever for 4 ...
         ... falls through to the next case ...

  end switch


Further more, whatever the default behaviour for the 'switch', it can be
adjusted on any of the 'case' clauses. This means that a by-default-break
switch, can use the 'fallthru' statement to explicitly override the break
default and fall through to the next case. 

  switch Foo do /* by default, break */
      case 1 then
         ... whatever for 1 ...
         fallthru /* explicitly falls through */

      case 2, 3 then
         ... whatever for 2 and 3 ...
         ... implied break here ...

      case 4 then
         ... whatever for 4 ...
         ... implied break here ...

  end switch

In short, Euphoria allows for both ideologies to exist, and in fact to
co-exist in peace. The standard default gives most protection from
mistakes, but for those coders that like to keep on the edge, they can code
with the level of risk that is acceptable to themselves.

I can see good reason for DPL to adopt a similar stance. I would suggest a
new keyword to make things easier for coders (after all, that's why we have
programming languages), but for those who see keywords as evil, I'm sure
that someone can come up with another syntax that avoids a new keyword (at
the expense of clarity) eg. "! break" or the old standby, "static" LOL.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Nov 15 2009
prev sibling next sibling parent reply MIURA Masahiro <echochamber gmail.com> writes:
On 11/16/2009 02:49 AM, Chad J wrote:

 So, switch-case statements are a frequent source of nasty bugs.  Fixing
 them (well) requires breaking backwards compatibility.

 Any chance this will happen for D2?


If I remember correctly, one of D's design policies is
that a D code that looks like C code should behave like C.
Are we giving up that policy?
Nov 16 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 16 Nov 2009 11:58:44 +0300, MIURA Masahiro <echochamber gmail.com>  
wrote:


 On 11/16/2009 02:49 AM, Chad J wrote:

 So, switch-case statements are a frequent source of nasty bugs.  Fixing
 them (well) requires breaking backwards compatibility.

 Any chance this will happen for D2?


 If I remember correctly, one of D's design policies is
 that a D code that looks like C code should behave like C.
 Are we giving up that policy?


Correction: either behave like C, or raise a compile-time error.
Missing break statement will not cause a different behavior. It will fail  
to compile.
Nov 16 2009
parent reply MIURA Masahiro <echochamber gmail.com> writes:
On 11/16/2009 06:16 PM, Denis Koroskin wrote:

 If I remember correctly, one of D's design policies is
 that a D code that looks like C code should behave like C.
 Are we giving up that policy?


 Correction: either behave like C, or raise a compile-time error.


Yes.  I should have written "a valid D code".


 Missing break statement will not cause a different behavior. It will
 fail to compile.


Could you clarify?  In you proposal, does a break statement
breaks out of the switch?  Then,

for (;;) {
     switch (foo) {
     case "FOO":
         break;
     }
}

In C, 'break' exits the for-loop.  In your proposal, it doesn't.
Nov 16 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 16 Nov 2009 12:48:09 +0300, MIURA Masahiro <echochamber gmail.com>  
wrote:


 On 11/16/2009 06:16 PM, Denis Koroskin wrote:

 If I remember correctly, one of D's design policies is
 that a D code that looks like C code should behave like C.
 Are we giving up that policy?


 Correction: either behave like C, or raise a compile-time error.


 Yes.  I should have written "a valid D code".


 Missing break statement will not cause a different behavior. It will
 fail to compile.


 Could you clarify?  In you proposal, does a break statement
 breaks out of the switch?  Then,

 for (;;) {
      switch (foo) {
      case "FOO":
          break;
      }
 }

 In C, 'break' exits the for-loop.  In your proposal, it doesn't.


Either I don't know C, or it breaks the switch, not the for-loop. In both  
languages. Before *and* after the proposed change.

There was no suggestion to remove breaks and make them implicit. The  
proposal was to make code flow control statements mandatory (either of  
break, return or goto).
Nov 16 2009
parent MIURA Masahiro <echochamber gmail.com> writes:
On 11/16/2009 06:55 PM, Denis Koroskin wrote:

 Either I don't know C, or it breaks the switch, not the for-loop. In
 both languages. Before *and* after the proposed change.


Arrrgh, please don't mind.  My mistake.  I'm sorry.
Nov 16 2009
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Nov 16, 09 17:48, MIURA Masahiro wrote:

 On 11/16/2009 06:16 PM, Denis Koroskin wrote:

 If I remember correctly, one of D's design policies is
 that a D code that looks like C code should behave like C.
 Are we giving up that policy?


 Correction: either behave like C, or raise a compile-time error.


 Yes. I should have written "a valid D code".


 Missing break statement will not cause a different behavior. It will
 fail to compile.


 Could you clarify?


switch (x) {
   case 2:
     doSomething();
         // At this point:
         // Compiles fine in C.
         // Falls through to the next (irrelevant) branch.
         // Compile-time error in D (missing "break;" or "goto case 3;")
   case 3:
     doSomeTotallyDifferentThing(x, ~x);
     break;
   ...
}


In you proposal, does a break statement

 breaks out of the switch? Then,

 for (;;) {
 switch (foo) {
 case "FOO":
 break;
 }
 }

 In C, 'break' exits the for-loop. In your proposal, it doesn't.


Check with you compiler. In C the inner "break" doesn't break the for loop.
Nov 16 2009
next sibling parent MIURA Masahiro <echochamber gmail.com> writes:
On 11/16/2009 07:05 PM, KennyTM~ wrote:

 Check with you compiler. In C the inner "break" doesn't break the for loop.


Yes that's right.  My mistake.
Nov 16 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
KennyTM~:


 switch (x) {
    case 2:
      doSomething();
          // At this point:
          // Compiles fine in C.
          // Falls through to the next (irrelevant) branch.
          // Compile-time error in D (missing "break;" or "goto case 3;")
    case 3:
      doSomeTotallyDifferentThing(x, ~x);
      break;
    ...
 }


Nice idea. 
"goto case 3;" isn't the nicest syntax to step to the following case, but it
has the advantage that it keeps working if you shuffle the cases.
So this design is acceptable, avoids introducing a third version of switch,
keeps the minimal compatibility necessary for C. If other people like it, then
it may be implemented in D2.
Anyone sees disadvantages?

Bye,
bearophile
Nov 16 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 16 Nov 2009 11:58:44 +0300, MIURA Masahiro <echochamber gmail.com>  
wrote:


 On 11/16/2009 02:49 AM, Chad J wrote:

 So, switch-case statements are a frequent source of nasty bugs.  Fixing
 them (well) requires breaking backwards compatibility.

 Any chance this will happen for D2?


 If I remember correctly, one of D's design policies is
 that a D code that looks like C code should behave like C.
 Are we giving up that policy?


It is a good policy to follow but there are cases where C behavior may  
differ from D behavior (when code is copy-pasted and not adjusted  
according to languages difference). I've just posted an example in a  
different thread:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=101322
Nov 16 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:


 (providing that empty fall-through case statements remain valid; 
 disallowing them would be really annoying).


What's bad about forcing people to write:
case A, B, C:

Instead of:
case A:
case B:
case C:
?

Bye,
bearophile
Nov 16 2009
next sibling parent reply Justin Johansson <no spam.com> writes:
bearophile wrote:

 Don:
 

 (providing that empty fall-through case statements remain valid; 
 disallowing them would be really annoying).


 
 What's bad about forcing people to write:
 case A, B, C:
 
 Instead of:
 case A:
 case B:
 case C:
 ?
 
 Bye,
 bearophile


I don't know about "forcing people" to write such but perhaps it could 
be an "option for people" :-)

Actually I quite like the brevity you propose but would it be a 
challenge for the comma operator?

While ago, I got D multi-dimensional array syntax messed up and declared 
such an animal as
int[3,4,5] which effectively ended up declaring the beast as int[5].

Cheers
Justin
Nov 16 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 16 Nov 2009 15:48:16 +0300, Justin Johansson <no spam.com> wrote:


 bearophile wrote:

 Don:


 (providing that empty fall-through case statements remain valid;  
 disallowing them would be really annoying).


  What's bad about forcing people to write:
 case A, B, C:
  Instead of:
 case A:
 case B:
 case C:
 ?
  Bye,
 bearophile


 I don't know about "forcing people" to write such but perhaps it could  
 be an "option for people" :-)

 Actually I quite like the brevity you propose but would it be a  
 challenge for the comma operator?

 While ago, I got D multi-dimensional array syntax messed up and declared  
 such an animal as
 int[3,4,5] which effectively ended up declaring the beast as int[5].

 Cheers
 Justin


Wow, this definitely needs to be bug-reported!
Nov 16 2009
parent Justin Johansson <no spam.com> writes:
Denis Koroskin wrote:

 On Mon, 16 Nov 2009 15:48:16 +0300, Justin Johansson <no spam.com> wrote:
 

 bearophile wrote:

 Don:


 (providing that empty fall-through case statements remain valid; 
 disallowing them would be really annoying).


  What's bad about forcing people to write:
 case A, B, C:
  Instead of:
 case A:
 case B:
 case C:
 ?
  Bye,
 bearophile


 I don't know about "forcing people" to write such but perhaps it could 
 be an "option for people" :-)

 Actually I quite like the brevity you propose but would it be a 
 challenge for the comma operator?

 While ago, I got D multi-dimensional array syntax messed up and 
 declared such an animal as
 int[3,4,5] which effectively ended up declaring the beast as int[5].

 Cheers
 Justin


 
 Wow, this definitely needs to be bug-reported!


Wilco.

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.bugs&article_id=19904
Nov 16 2009
prev sibling parent grauzone <none example.net> writes:
Justin Johansson wrote:

 bearophile wrote:

 Don:


 (providing that empty fall-through case statements remain valid; 
 disallowing them would be really annoying).


 What's bad about forcing people to write:
 case A, B, C:

 Instead of:
 case A:
 case B:
 case C:
 ?

 Bye,
 bearophile


 
 I don't know about "forcing people" to write such but perhaps it could 
 be an "option for people" :-)
 
 Actually I quite like the brevity you propose but would it be a 
 challenge for the comma operator?
 
 While ago, I got D multi-dimensional array syntax messed up and declared 
 such an animal as
 int[3,4,5] which effectively ended up declaring the beast as int[5].


The comma operator is another piece of C cruft that needs to go.


 Cheers
 Justin
Nov 16 2009
prev sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:

 Don:
 

 (providing that empty fall-through case statements remain valid; 
 disallowing them would be really annoying).


 
 What's bad about forcing people to write:
 case A, B, C:
 
 Instead of:
 case A:
 case B:
 case C:
 ?
 
 Bye,
 bearophile


(1) "case A, B, C:" implies a relationship between A, B, and C, which 
might not exist. They may have nothing in common.
(2) it's an extremely common coding style in C, C++.
(3) it's more difficult to read.
Nov 16 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:


 (1) "case A, B, C:" implies a relationship between A, B, and C, which 
 might not exist. They may have nothing in common.


It's just a list of things, it's a syntax people adapts too. Here too there's
no relationship between x and foo:
int x, foo;



 (2) it's an extremely common coding style in C, C++.


If automatic fall-through becomes a syntax error, then allowing it for empty
case statements is a special case of a special case. This kind of complexity
kills languages. As they say in Python Zen:
Special cases aren't special enough to break the rules.
And this is D.



 (3) it's more difficult to read.


You can put items in one column anyway, so instead of:

case someverylongcase:
case anotherverylongcase:
case thelastverylongcase:

You can write:

case someverylongcase,
     anotherverylongcase,
     thelastverylongcase:

This is not so unreadable.

----------------------

Justin Johansson:


 Actually I quite like the brevity you propose but would
 it be a challenge for the comma operator?


That's already standard D syntax :-)
http://codepad.org/ByvTAs27

Bye,
bearophile
Nov 16 2009
parent Justin Johansson <no spam.com> writes:
bearophile wrote:

 Don:
 

 (1) "case A, B, C:" implies a relationship between A, B, and C, which 
 might not exist. They may have nothing in common.


 
 It's just a list of things, it's a syntax people adapts too. Here too there's
no relationship between x and foo:
 int x, foo;
 
 

 (2) it's an extremely common coding style in C, C++.


 
 If automatic fall-through becomes a syntax error, then allowing it for empty
case statements is a special case of a special case. This kind of complexity
kills languages. As they say in Python Zen:
 Special cases aren't special enough to break the rules.
 And this is D.
 
 

 (3) it's more difficult to read.


 
 You can put items in one column anyway, so instead of:
 
 case someverylongcase:
 case anotherverylongcase:
 case thelastverylongcase:
 
 You can write:
 
 case someverylongcase,
      anotherverylongcase,
      thelastverylongcase:
 
 This is not so unreadable.
 
 ----------------------
 
 Justin Johansson:
 

 Actually I quite like the brevity you propose but would
 it be a challenge for the comma operator?


 
 That's already standard D syntax :-)
 http://codepad.org/ByvTAs27
 
 Bye,
 bearophile



 That's already standard D syntax :-)


Okay, thanks for reminding me.**


 What's bad about forcing people to write case A, B, C


So your use of the word "forcing" was quite intentional?

Cheers.  Must go now to attend to some fall-through cases in my
switch statements.**  Justin.
Nov 16 2009
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 16 Nov 2009 14:34:37 +0100, Don wrote:


 bearophile wrote:

 Don:
 

 (providing that empty fall-through case statements remain valid; 
 disallowing them would be really annoying).


 
 What's bad about forcing people to write:
 case A, B, C:
 
 Instead of:
 case A:
 case B:
 case C:
 ?
 
 Bye,
 bearophile


 
 (1) "case A, B, C:" implies a relationship between A, B, and C, which 
 might not exist. They may have nothing in common.
 (2) it's an extremely common coding style in C, C++.
 (3) it's more difficult to read.


(1)  case A:
     case B:
     case C:
   implies that there is no relationship between A,B, and C, but which
might actually exist. They may have something common.
(2) it's an extremely common writing style in human languages, thus aids
readability.
(3)  case A:
     case B:
     case C:
   is ambiguous. It looks like the coder put in place markers for intended
code but forgot the code.


-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Nov 16 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 16 Nov 2009 23:36:38 +0300, Derek Parnell <derek psych.ward> wrote:


 On Mon, 16 Nov 2009 14:34:37 +0100, Don wrote:


 bearophile wrote:

 Don:


 (providing that empty fall-through case statements remain valid;
 disallowing them would be really annoying).


 What's bad about forcing people to write:
 case A, B, C:

 Instead of:
 case A:
 case B:
 case C:
 ?

 Bye,
 bearophile


 (1) "case A, B, C:" implies a relationship between A, B, and C, which
 might not exist. They may have nothing in common.
 (2) it's an extremely common coding style in C, C++.
 (3) it's more difficult to read.


 (1)  case A:
      case B:
      case C:
    implies that there is no relationship between A,B, and C, but which
 might actually exist. They may have something common.
 (2) it's an extremely common writing style in human languages, thus aids
 readability.
 (3)  case A:
      case B:
      case C:
    is ambiguous. It looks like the coder put in place markers for  
 intended
 code but forgot the code.


When porting some C++ code to D (okay, it was DMDFE), I had exact same  
issue. There is the following macro defined:

#define CASE_BASIC_TYPES			\
	case TOKwchar: case TOKdchar:		\
	case TOKbit: case TOKbool: case TOKchar:	\
	case TOKint8: case TOKuns8:		\
	case TOKint16: case TOKuns16:		\
	case TOKint32: case TOKuns32:		\
	case TOKint64: case TOKuns64:		\
	case TOKfloat32: case TOKfloat64: case TOKfloat80:		\
	case TOKimaginary32: case TOKimaginary64: case TOKimaginary80:	\
	case TOKcomplex32: case TOKcomplex64: case TOKcomplex80:	\
	case TOKvoid

and if was used (and got translated to D) as follows:

switch (token) {
     case TOKidentifier:
     case TOKenum:
     case TOKstruct:
     case TOKimport:
     CASE_BASIC_TYPES:
}

Did you noticed it already? It is a valid C code *but* has different  
semantics! In D, CASE_BASIC_TYPES is merely a label, and it does just  
nothing. Needless to say the code compiled successfully, but produced  
weird error messages at run-time.

BTW, if a macro was declared as

#define BASIC_TYPES			\
	     TOKwchar: case TOKdchar:		\
	case TOKbit: case TOKbool: case TOKchar:	\
	case TOKint8: case TOKuns8:		\
	case TOKint16: case TOKuns16:		\
	case TOKint32: case TOKuns32:		\
	case TOKint64: case TOKuns64:		\
	case TOKfloat32: case TOKfloat64: case TOKfloat80:		\
	case TOKimaginary32: case TOKimaginary64: case TOKimaginary80:	\
	case TOKcomplex32: case TOKcomplex64: case TOKcomplex80:	\
	case TOKvoid

(note an absence of the first case) then it would cause compile-time error  
instead of run-time bugs. Usage:

switch (token) {
     case TOKidentifier:
     case TOKenum:
     case TOKstruct:
     case TOKimport:
     case BASIC_TYPES:
}
Nov 16 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Denis Koroskin wrote:

 BTW, if a macro was declared as
 
 #define BASIC_TYPES            \
          TOKwchar: case TOKdchar:        \
     case TOKbit: case TOKbool: case TOKchar:    \
     case TOKint8: case TOKuns8:        \
     case TOKint16: case TOKuns16:        \
     case TOKint32: case TOKuns32:        \
     case TOKint64: case TOKuns64:        \
     case TOKfloat32: case TOKfloat64: case TOKfloat80:        \
     case TOKimaginary32: case TOKimaginary64: case TOKimaginary80:    \
     case TOKcomplex32: case TOKcomplex64: case TOKcomplex80:    \
     case TOKvoid
 
 (note an absence of the first case) then it would cause compile-time 
 error instead of run-time bugs. Usage:
 
 switch (token) {
     case TOKidentifier:
     case TOKenum:
     case TOKstruct:
     case TOKimport:
     case BASIC_TYPES:
 }


I like that. Great suggestion!
Nov 16 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Derek Parnell wrote:

 On Mon, 16 Nov 2009 14:34:37 +0100, Don wrote:
 

 bearophile wrote:

 Don:


 (providing that empty fall-through case statements remain valid; 
 disallowing them would be really annoying).


 What's bad about forcing people to write:
 case A, B, C:

 Instead of:
 case A:
 case B:
 case C:
 ?

 Bye,
 bearophile


 (1) "case A, B, C:" implies a relationship between A, B, and C, which 
 might not exist. They may have nothing in common.
 (2) it's an extremely common coding style in C, C++.
 (3) it's more difficult to read.


 
 (1)  case A:
      case B:
      case C:
    implies that there is no relationship between A,B, and C, but which
 might actually exist. They may have something common.


Yes, of course! In which situation, you use case A, B, C:
I'm not arguing AGAINST that syntax, which already exists!

Your other two comments aren't worth responding to.
Nov 17 2009
parent Derek Parnell <derek psych.ward> writes:
On Tue, 17 Nov 2009 09:05:48 +0100, Don wrote:


 Your other two comments aren't worth responding to.


I apologize.  I also don't know what I said to offend you. I've taken steps
to make sure it doesn't happen again.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Nov 17 2009
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu Wrote:


 Chad J wrote:

 So, switch-case statements are a frequent source of nasty bugs.  Fixing
 them (well) requires breaking backwards compatibility.
 
 Any chance this will happen for D2?
 
 (This is intended as more of a reminder and simple curiosity than a
 discussion.)


 
 I wish very much that a transferring control flow statement (break, 
 return, goto etc.) is required at the end of each case. Then, the rare 
 case when you want to break through is easy to implement as goto case 
 xxx; and all is good.
 
 Walter's answer to that has put me to silence for good. "But I use 
 fall-through all the time!" I then knew the feature will never make it.


As long as it's possible to enumerate a list of matches for one case statement
then I'm all for it.  I very rarely use fall-through in any of my code but
lexers/parser, where I enumerate lists of matches everywhere.

I'll admit to still being a bit peeved that I have to add default conditions
where I only want a break, etc, but I'll concede that the safety is worth what
I feel is unnecessary code.  Just because "I never hit those bugs in my code"
doesn't mean they aren't a common source of problems.
Nov 16 2009