I just found out about this language and was disappointed to notice that C++'s switch syntax remains unchanged.  One of the most annoying mistakes in C++ is forgetting to place a break statement in switch.  Breaks should be implicit, and fallthrough should be explicit as it is more rare.  So something like:

switch (foo) {
case 0:
//Do something, then fall through
continue;
case 1:
//Do something; break is implicit
default:
//Panic
}

Another thing that might be cool would be mathematical-style transitive
comparisons, e.g. 1
if ([x < y < 45]) //...
would expand internally to the more cumbersome
if (x < y && y < 45) //...
e.g. 2
if (bar == [4 || 75 || 213]) //...
might become
if (bar == 4 || bar == 75 || bar == 213) //...
Although the two examples above somewhat strain the construct.

Alksub

On Sat, 01 Jul 2006 17:33:47 +1000, Alksub <Alksub_member@pathlink.com> wrote:

> I just found out about this language and was disappointed to notice that C++'s
> switch syntax remains unchanged.  One of the most annoying mistakes in C++ is
> forgetting to place a break statement in switch.  Breaks should be implicit, and
> fallthrough should be explicit as it is more rare.  So something like:
>
> switch (foo) {
> case 0:
> //Do something, then fall through
> continue;
> case 1:
> //Do something; break is implicit
> default:
> //Panic
> }
>
> Another thing that might be cool would be mathematical-style transitive
> comparisons, e.g. 1
> if ([x < y < 45]) //...
> would expand internally to the more cumbersome
> if (x < y && y < 45) //...
> e.g. 2
> if (bar == [4 || 75 || 213]) //...
> might become
> if (bar == 4 || bar == 75 || bar == 213) //...
> Although the two examples above somewhat strain the construct.

These and other great ideas have been mentioned before. At best, these sort of improvements will not be worked on until after v1.0 has been released. However, the better semantics for switch is never going to get implemented 'cos it will scare away too many C/C++ people, even if those people would like to be more helpful. I think it has to do with the cost of porting C/C++ code to D.


-- 
Derek Parnell
Melbourne, Australia

The idea with 'continue' and implicit 'break' for a fallthrough is great. I second that.

I have had much more errors with accidentally fallthroughs than I used it productive. And if I use fallthrough such rarely, its good to write it explicit that it should really fallthrough in this case.

> These and other great ideas have been mentioned before. At best, these sort of improvements will not be worked on until after v1.0 has been released. However, the better semantics for switch is never going to get implemented 'cos it will scare away too many C/C++ people, even if those people would like to be more helpful. I think it has to do with the cost of porting C/C++ code to D.
> 
> 
> --Derek Parnell
> Melbourne, Australia

I don't think so. D is not C++. If a C++ programmer wants to have C++ he will not change to another programming language.

A possibility to reduce the cost of porting C++ code, can be:
Make a warning for missing break or continue statement at the end of a
case. Then you can easily go through the code and correct the wanted
fallthrough statements.

But there is a inconsistence:

switch( i ){
case 0:
	...
case 1:	// problem with implicit break
case 2:
	...
default:
	...
}

should become:
switch( i ){
case 0:
	...
case 1, 2: // this solves the problem
	...
default:
	...
}

"Frank Benoit" <keinfarbton@nospam.xyz> wrote:
> The idea with 'continue' and implicit 'break' for a fallthrough is great. I second that.

And I most definitely third the suggestion. :)

> I have had much more errors with accidentally fallthroughs than I used it productive. And if I use fallthrough such rarely, its good to write it explicit that it should really fallthrough in this case.

On too many occasions, working in C, C++ or D, I've had accidental fall-throughs. (Too much coding FSM's with switch statements tend to cause that.)

If it breaks existing code, so what? Or about making it that tiny bit harder to translate C or C++ code? We're still at pre-1.0 - any code breaking is to be expected (re the discussion on implicit const).

It seems much more sensible that the break be implicit, instead of the continue. The break, at least in code I've written, is on about 90% on the cases, with the rest being fall-through. But if we can't get this, then at least *warn* of a missing continue or break at the end of a case; that way, the code will be much safer when we see we're missing one or the other, and explicitly put it in.

"Frank Benoit" <keinfarbton@nospam.xyz> wrote:
> But there is a inconsistence:
>
> switch( i ){
> case 0:
> ...
> case 1: // problem with implicit break
> case 2:
> ...
> default:
> ...
> }
>
> should become:
> switch( i ){
> case 0:
> ...
> case 1, 2: // this solves the problem
> ...
> default:
> ...
> }

Or even borrow a bit from array slices, and do something akin to

case 1..4, 8..12:

to have it trigger on 1, 2, 3, 4, 8, 9, 10, 11 and 12.

Rioshin an'Harthen wrote:
> "Frank Benoit" <keinfarbton@nospam.xyz> wrote:
> 
[...]
> It seems much more sensible that the break be implicit, instead of the continue. The break, at least in code I've written, is on about 90% on the cases, with the rest being fall-through. But if we can't get this, then at least *warn* of a missing continue or break at the end of a case; that way, the code will be much safer when we see we're missing one or the other, and explicitly put it in. 
> 
> 
PLEASE don't make it *implicit*. Requirer an explicit control statement[*] or leave it as it is. Making the same code legal in C/C++ and D but with different semantics is asking for trouble.

[*] In addition to the break and continue, goto (in all its forms), throw, return and assert might also end a case.