www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Lang. suggestion: auto-fallthrough and comparison shorthands

reply Alksub <Alksub_member pathlink.com> writes:
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
Jul 01 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
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 th=


at  =


 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 transitiv=


e

 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 =3D=3D [4 || 75 || 213]) //...
 might become
 if (bar =3D=3D 4 || bar =3D=3D 75 || bar =3D=3D 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
Jul 01 2006
parent Frank Benoit <keinfarbton nospam.xyz> writes:
 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.
Jul 01 2006
prev sibling parent reply Frank Benoit <keinfarbton nospam.xyz> writes:
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.
Jul 01 2006
next sibling parent reply Frank Benoit <keinfarbton nospam.xyz> writes:
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:
	...
}
Jul 01 2006
parent "Rioshin an'Harthen" <rharth75 hotmail.com> writes:
"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.
Jul 01 2006
prev sibling parent reply "Rioshin an'Harthen" <rharth75 hotmail.com> writes:
"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.
Jul 01 2006
parent BCS <BCS pathlink.com> writes:
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.
Jul 01 2006