Just had a quick look at the switch statement.

I noticed the syntax is:

switch (foobar)
{
case 0:
dostuff();
// I've forgotten to break; all is lost.
case 1:
domorestuffIdidntreallywantto();
break;
default:
}

This isn't such a good idea. The default behaviour is really unsafe. I would suggest a 'nobreak' statement for cases where you really do want the code to fall through; otherwise  the compiler probably should fail to compile (possibly switcheable off with a compiler option.)

e.g.

switch (foobar)
{
case 0:
dostuff();
nobreak; // we fall through, but that's fine.
case 1:
case 2: // note no nobreak required (although I wouldn't cry if it was)
domorestuff();
break;
default:
}

Anyway, just an idea; probably a very good one IMNHO though.

You might also consider the same idea in empty if and for statements.

-Ian

I like the idea of a nobreak statement ( this has been a popular topic) , I
think the reason for keeping this is backward compatibility ( on a user
level ).

I always hated this behavior, and could never understand why this was the default.  Can we change it ?  Taking a vote might be helpful to Walter.  I vote we fix this beast once and for all!

Charles

"Ian Woollard" <Ian_member@pathlink.com> wrote in message news:bk5nri$14cm$1@digitaldaemon.com...
> Just had a quick look at the switch statement.
>
> I noticed the syntax is:
>
> switch (foobar)
> {
> case 0:
> dostuff();
> // I've forgotten to break; all is lost.
> case 1:
> domorestuffIdidntreallywantto();
> break;
> default:
> }
>
> This isn't such a good idea. The default behaviour is really unsafe. I
would
> suggest a 'nobreak' statement for cases where you really do want the code
to
> fall through; otherwise  the compiler probably should fail to compile
(possibly
> switcheable off with a compiler option.)
>
> e.g.
>
> switch (foobar)
> {
> case 0:
> dostuff();
> nobreak; // we fall through, but that's fine.
> case 1:
> case 2: // note no nobreak required (although I wouldn't cry if it was)
> domorestuff();
> break;
> default:
> }
>
> Anyway, just an idea; probably a very good one IMNHO though.
>
> You might also consider the same idea in empty if and for statements.
>
> -Ian

In article <bk5o47$15o3$1@digitaldaemon.com>, Charles Sanders says...
>I like the idea of a nobreak statement ( this has been a popular topic) , I
>think the reason for keeping this is backward compatibility ( on a user
>level ).

Provided the nobreak statement is optional (just a nasty compiler warning if left out), or mandatory but the compiler has a flag to make it ignore it's omission (but still warn- my colleagues ARE out to get me :-) ), then backward compatibility is, in practice, a non issue.

>Charles
>
>"Ian Woollard" <Ian_member@pathlink.com> wrote in message news:bk5nri$14cm$1@digitaldaemon.com...
>> Just had a quick look at the switch statement.
>>
>> I noticed the syntax is:
>>
>> switch (foobar)
>> {
>> case 0:
>> dostuff();
>> // I've forgotten to break; all is lost.
>> case 1:
>> domorestuffIdidntreallywantto();
>> break;
>> default:
>> }
>>
>> This isn't such a good idea. The default behaviour is really unsafe. I
>would
>> suggest a 'nobreak' statement for cases where you really do want the code
>to
>> fall through; otherwise  the compiler probably should fail to compile
>(possibly
>> switcheable off with a compiler option.)
>>
>> e.g.
>>
>> switch (foobar)
>> {
>> case 0:
>> dostuff();
>> nobreak; // we fall through, but that's fine.
>> case 1:
>> case 2: // note no nobreak required (although I wouldn't cry if it was)
>> domorestuff();
>> break;
>> default:
>> }
>>
>> Anyway, just an idea; probably a very good one IMNHO though.
>>
>> You might also consider the same idea in empty if and for statements.
>>
>> -Ian
>
>

I like the idea too (and I know C# does it), but I wonder if there are fewer errors caused by this than by  if ( x = y )  which Walter has done away with, although I don't entirely agree with the way he did.

In article <bk5o47$15o3$1@digitaldaemon.com>, Charles Sanders says...
>
>I like the idea of a nobreak statement ( this has been a popular topic) , I
>think the reason for keeping this is backward compatibility ( on a user
>level ).
>
>I always hated this behavior, and could never understand why this was the default.  Can we change it ?  Taking a vote might be helpful to Walter.  I vote we fix this beast once and for all!
>
>Charles
>
>"Ian Woollard" <Ian_member@pathlink.com> wrote in message news:bk5nri$14cm$1@digitaldaemon.com...
>> Just had a quick look at the switch statement.
>>
>> I noticed the syntax is:
>>
>> switch (foobar)
>> {
>> case 0:
>> dostuff();
>> // I've forgotten to break; all is lost.
>> case 1:
>> domorestuffIdidntreallywantto();
>> break;
>> default:
>> }
>>
>> This isn't such a good idea. The default behaviour is really unsafe. I
>would
>> suggest a 'nobreak' statement for cases where you really do want the code
>to
>> fall through; otherwise  the compiler probably should fail to compile
>(possibly
>> switcheable off with a compiler option.)
>>
>> e.g.
>>
>> switch (foobar)
>> {
>> case 0:
>> dostuff();
>> nobreak; // we fall through, but that's fine.
>> case 1:
>> case 2: // note no nobreak required (although I wouldn't cry if it was)
>> domorestuff();
>> break;
>> default:
>> }
>>
>> Anyway, just an idea; probably a very good one IMNHO though.
>>
>> You might also consider the same idea in empty if and for statements.
>>
>> -Ian
>
>

John Boucher -- Quite contrary
The King had Humpty pushed.

> >I like the idea of a nobreak statement ( this has been a popular topic) ,
I
> >think the reason for keeping this is backward compatibility ( on a user
> >level ).
>
> Provided the nobreak statement is optional (just a nasty compiler warning
if
> left out), or mandatory but the compiler has a flag to make it ignore it's
> omission (but still warn- my colleagues ARE out to get me :-) ), then
backward
> compatibility is, in practice, a non issue.
>

I think that nobreak is a good keyword and should be required if no it would
otherwise fall-through. That is, we ne it if there are no break, return,
throw,
continue or goto statement (or similar).

I think that compatibility is not a good reason in this case to make it
facultative. In my opinion even a good programmer might forget one
or two break in a year and spend a few minutes to find a bug that
could be easily prevented by the compiler by requiring explicit
exit... IMO, the time saved in debugging for common programmers
worth well the few added keystroke... and if break is optional, we
would be safer than C++ with less code to write in typical application
(since more than 90% of case needs a break).

 For compatibility with C++, with should allows to still uses break
(easy conversion from C++ to D) and define nobreak as an empty
statement in C++ (for easier conversion in the other direction).

#define nobreak (void)0    /* in C++ */

That way, by using both break and nobreak the code is portable between C++ and D.

Also, I would suggest to make these kind of change soon before a lot of code depend on it...

I wote that fall-through must be explicitly asked (nobreak or something else)... For weither break is required or optional, I would prefer optional but I can live with if required...

And I like nobreak as it is explicit, short and documentative...
but labelled jump is acceptable... and a bit safer if the
order is modified!

> I like the idea too (and I know C# does it), but I wonder if there are
fewer
> errors caused by this than by  if ( x = y )  which Walter has done away
with,
> although I don't entirely agree with the way he did.

Good point, I love the assignment's in conditionals too.  That was one of the problems I had with python.  Walter what can we do ( if anything ) to convince you to allow this and the nobreak ?

Charles
"John Boucher" <John_member@pathlink.com> wrote in message
news:bk5pkl$1a5p$1@digitaldaemon.com...
> I like the idea too (and I know C# does it), but I wonder if there are
fewer
> errors caused by this than by  if ( x = y )  which Walter has done away
with,
> although I don't entirely agree with the way he did.
>
> In article <bk5o47$15o3$1@digitaldaemon.com>, Charles Sanders says...
> >
> >I like the idea of a nobreak statement ( this has been a popular topic) ,
I
> >think the reason for keeping this is backward compatibility ( on a user
> >level ).
> >
> >I always hated this behavior, and could never understand why this was the default.  Can we change it ?  Taking a vote might be helpful to Walter.
I
> >vote we fix this beast once and for all!
> >
> >Charles
> >
> >"Ian Woollard" <Ian_member@pathlink.com> wrote in message news:bk5nri$14cm$1@digitaldaemon.com...
> >> Just had a quick look at the switch statement.
> >>
> >> I noticed the syntax is:
> >>
> >> switch (foobar)
> >> {
> >> case 0:
> >> dostuff();
> >> // I've forgotten to break; all is lost.
> >> case 1:
> >> domorestuffIdidntreallywantto();
> >> break;
> >> default:
> >> }
> >>
> >> This isn't such a good idea. The default behaviour is really unsafe. I
> >would
> >> suggest a 'nobreak' statement for cases where you really do want the
code
> >to
> >> fall through; otherwise  the compiler probably should fail to compile
> >(possibly
> >> switcheable off with a compiler option.)
> >>
> >> e.g.
> >>
> >> switch (foobar)
> >> {
> >> case 0:
> >> dostuff();
> >> nobreak; // we fall through, but that's fine.
> >> case 1:
> >> case 2: // note no nobreak required (although I wouldn't cry if it was)
> >> domorestuff();
> >> break;
> >> default:
> >> }
> >>
> >> Anyway, just an idea; probably a very good one IMNHO though.
> >>
> >> You might also consider the same idea in empty if and for statements.
> >>
> >> -Ian
> >
> >
>
> John Boucher -- Quite contrary
> The King had Humpty pushed.

I think that both break and nobreak (I'd prefer "fallthrough") were
required. That's the safest (albeit the most verbose) way to go

"Philippe Mori" <philippe_mori@hotmail.com> wrote in message news:bk5uqe$1tnn$1@digitaldaemon.com...
> > >I like the idea of a nobreak statement ( this has been a popular topic)
,
> I
> > >think the reason for keeping this is backward compatibility ( on a user
> > >level ).
> >
> > Provided the nobreak statement is optional (just a nasty compiler
warning
> if
> > left out), or mandatory but the compiler has a flag to make it ignore
it's
> > omission (but still warn- my colleagues ARE out to get me :-) ), then
> backward
> > compatibility is, in practice, a non issue.
> >
>
> I think that nobreak is a good keyword and should be required if no it
would
> otherwise fall-through. That is, we ne it if there are no break, return,
> throw,
> continue or goto statement (or similar).
>
> I think that compatibility is not a good reason in this case to make it
> facultative. In my opinion even a good programmer might forget one
> or two break in a year and spend a few minutes to find a bug that
> could be easily prevented by the compiler by requiring explicit
> exit... IMO, the time saved in debugging for common programmers
> worth well the few added keystroke... and if break is optional, we
> would be safer than C++ with less code to write in typical application
> (since more than 90% of case needs a break).
>
>  For compatibility with C++, with should allows to still uses break
> (easy conversion from C++ to D) and define nobreak as an empty
> statement in C++ (for easier conversion in the other direction).
>
> #define nobreak (void)0    /* in C++ */
>
> That way, by using both break and nobreak the code is portable between C++ and D.
>
> Also, I would suggest to make these kind of change soon before a lot of code depend on it...
>
> I wote that fall-through must be explicitly asked (nobreak or something else)... For weither break is required or optional, I would prefer optional but I can live with if required...
>
> And I like nobreak as it is explicit, short and documentative...
> but labelled jump is acceptable... and a bit safer if the
> order is modified!
>
>
>

Hmmm, a compiler switch to say whether or not it is required... kinda starting to border on being a pragma, isn't it?

In article <bk5pk9$1a54$1@digitaldaemon.com>, Ian Woollard says...
>
>In article <bk5o47$15o3$1@digitaldaemon.com>, Charles Sanders says...
>>I like the idea of a nobreak statement ( this has been a popular topic) , I
>>think the reason for keeping this is backward compatibility ( on a user
>>level ).
>
>Provided the nobreak statement is optional (just a nasty compiler warning if left out), or mandatory but the compiler has a flag to make it ignore it's omission (but still warn- my colleagues ARE out to get me :-) ), then backward compatibility is, in practice, a non issue.
>
>>Charles

Matthew Wilson wrote:
> 
> I think that both break and nobreak (I'd prefer "fallthrough") were
> required. That's the safest (albeit the most verbose) way to go
> 

Exactly. I would also vote to make "break or nobreak" mandatory.
So you can convert code from all C family languages without any risk.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

> > I think that both break and nobreak (I'd prefer "fallthrough") were
> > required. That's the safest (albeit the most verbose) way to go
> >
>
> Exactly. I would also vote to make "break or nobreak" mandatory.
> So you can convert code from all C family languages without any risk.

Yes, indeed. That was what I meant (and why I meant it :) ).