Don Clugston wrote:
> Lionello Lunesu wrote:
>>> 7) From the FAQ: 
>>
>>> Many people have asked for a requirement that there be a break
>>  > between cases in a switch statement, that C's behavior of
>>  > silently falling through is the cause of many bugs.
>>  > The reason D doesn't change this is for the same reason that
>>  > integral promotion rules and operator precedence rules were
>>  > kept the same - to make code that looks the same as in C
>>  > operate the same. If it had subtly different semantics, it
>>  > will cause frustratingly subtle bugs.
>>
>>> I agree with both points of view. My idea: calling this
>>  > statement differently (like caseof) instead of "switch"
>>  > (like in Pascal), so you can change its semantics too,
>>  > removing the falling through (you may use the Pascal
>>  > semantic too).
>>
>> Sorry to hijack your point here, but this got me thinking:
>>
>> Why not use "continue" for seeping through to the next case statement? DMD could then complain if a case does not end with break/continue/goto/return and silently insert a assert(0) before each case (the way it does for functions that return a value.)
> 
> Doesn't
> 
> for (c;;) {
>   switch (c) {
>   case 'a': continue;
>   case 'b': break;
>   }
> }
> 
> already have a meaning?

Yes, I've done that too, but honestly I'd be the first one to admit that it isn't very clear. In fact, I'd go so far as to call it a reason to attach a meaning to "continue" in a switch/case.

As mentioned, it would break existing code :(

L.

bearophile wrote:
>
> 7) From the FAQ: >Many people have asked for a requirement that there be a break between cases in a switch statement, that C's behavior of silently falling through is the cause of many bugs. The reason D doesn't change this is for the same reason that integral promotion rules and operator precedence rules were kept the same - to make code that looks the same as in C operate the same. If it had subtly different semantics, it will cause frustratingly subtle bugs.<
> 
> I agree with both points of view. My idea: calling this statement differently (like caseof) instead of "switch" (like in Pascal), so you can change its semantics too, removing the falling through (you may use the Pascal semantic too).
> 

how about keep switch as is and add "select" with the no fall through.

I wouldn't mind having nothing done about this, but don't change the switch!

BCS wrote:
> how about keep switch as is and add "select" with the no fall through.
> 
> I wouldn't mind having nothing done about this, but don't change the switch!
Does just using goto case; or goto case Location; make a good substitute? At least it makes the fall through in a switch statement quite explicit.

 - Paul

Reply to Paul,

> BCS wrote:
> 
>> how about keep switch as is and add "select" with the no fall
>> through.
>> 
>> I wouldn't mind having nothing done about this, but don't change the
>> switch!
>> 
> Does just using goto case; or goto case Location; make a good
> substitute? At least it makes the fall through in a switch statement
> quite explicit.
> 
> - Paul
> 

Believe it or not, I may actually want fall through more often then not, and in some of those cases the goto case #; option is not at all pleasant.

Lionello Lunesu wrote:
> Don Clugston wrote:
>> Lionello Lunesu wrote:
>>>> 7) From the FAQ: 
>>>
>>>> Many people have asked for a requirement that there be a break
>>>  > between cases in a switch statement, that C's behavior of
>>>  > silently falling through is the cause of many bugs.
>>>  > The reason D doesn't change this is for the same reason that
>>>  > integral promotion rules and operator precedence rules were
>>>  > kept the same - to make code that looks the same as in C
>>>  > operate the same. If it had subtly different semantics, it
>>>  > will cause frustratingly subtle bugs.
>>>
>>>> I agree with both points of view. My idea: calling this
>>>  > statement differently (like caseof) instead of "switch"
>>>  > (like in Pascal), so you can change its semantics too,
>>>  > removing the falling through (you may use the Pascal
>>>  > semantic too).
>>>
>>> Sorry to hijack your point here, but this got me thinking:
>>>
>>> Why not use "continue" for seeping through to the next case statement? DMD could then complain if a case does not end with break/continue/goto/return and silently insert a assert(0) before each case (the way it does for functions that return a value.)
>>
>> Doesn't
>>
>> for (c;;) {
>>   switch (c) {
>>   case 'a': continue;
>>   case 'b': break;
>>   }
>> }
>>
>> already have a meaning?
> 
> Yes, I've done that too, but honestly I'd be the first one to admit that it isn't very clear. In fact, I'd go so far as to call it a reason to attach a meaning to "continue" in a switch/case.

Including making it illegal. Since there's no short syntax to break out of out an outer loop from inside a switch, I don't see why a bare 'continue' is legal.
(actually the spec doesn't mention it, so it's a bit ambiguous).
Especially since "continue <identifier>;" and "break <identifier>;" exist, and are clearer.

> As mentioned, it would break existing code :(

Searching for "continue; case" on google gave many hits for C-family languages. So even if it didn't break any existing D code, it would still be a problem for porting from other languages. I think that's a show-stopper. Which is a shame, because I do like the idea.