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

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

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/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>

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

Andrei

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?

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.

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.

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

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

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.

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.