November 16, 2009
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.
November 16, 2009
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.
November 16, 2009
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.
November 16, 2009
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
November 16, 2009
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?

November 16, 2009
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).

It hasn't hurt C# at all...

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
November 16, 2009
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
November 16, 2009
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
November 16, 2009
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
November 16, 2009
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.