www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Switch and break

reply RenatoL <rexlen gmail.com> writes:
Just curious: why in D we are not obligated to use break in every
branch of a swicth structure? That is:
	switch (i)
	{
		case 1:
		writeln("You wrote 1");
		case 2:
		writeln("You wrote 2");
		case 3:
		writeln("You wrote 3");
		default:
		writeln("I said: 1 or 2 or 3!");
        }


and if you want to play with fall through you have to make some
trick. Again this behaviour of D seems a bit buggy, to me. Are
there design reasons?
Jan 19 2012
next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 19/01/12 9:55 PM, RenatoL wrote:
 Just curious: why in D we are not obligated to use break in every
 branch of a swicth structure? That is:
 	switch (i)
 	{
 		case 1:
 		writeln("You wrote 1");
 		case 2:
 		writeln("You wrote 2");
 		case 3:
 		writeln("You wrote 3");
 		default:
 		writeln("I said: 1 or 2 or 3!");
          }


 and if you want to play with fall through you have to make some
 trick. Again this behaviour of D seems a bit buggy, to me. Are
 there design reasons?
Consistency with C and C++ mainly. Some people find it convenient, but it is unarguably a frequent source of bugs that we could do without.
Jan 19 2012
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, January 19, 2012 22:10:19 Peter Alexander wrote:
 Consistency with C and C++ mainly.
 
 Some people find it convenient, but it is unarguably a frequent source
 of bugs that we could do without.
I'd be _very_ annoying if you couldn't do fall-through with switch-statements. That's a major feature and important for case statements IMHO. However, making fallthrough be explicit as D now does (with -w anyway) is definitely an improvement. - Jonathan M Davis
Jan 19 2012
prev sibling parent Matej Nanut <matejnanut gmail.com> writes:
On 20 January 2012 00:46, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 On Thursday, January 19, 2012 22:10:19 Peter Alexander wrote:
 Consistency with C and C++ mainly.

 Some people find it convenient, but it is unarguably a frequent source
 of bugs that we could do without.
I'd be _very_ annoying if you couldn't do fall-through with switch-statem=
ents.
 That's a major feature and important for case statements IMHO. However, m=
aking
 fallthrough be explicit as D now does (with -w anyway) is definitely an
 improvement.

 - Jonathan M Davis
I like the error DMD (-w) gives in this situation a lot. It has saved me precious minutes of debugging on more than one occasion. :) And I never liked =E2=80=98warning:=E2=80=99s anyway. If something is dange= rous enough to warrant a warning, the compiler may just as well enforce it in the language and be done with it. Matej
Jan 19 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/19/2012 10:55 PM, RenatoL wrote:
 Just curious: why in D we are not obligated to use break in every
 branch of a swicth structure? That is:
 	switch (i)
 	{
 		case 1:
 		writeln("You wrote 1");
 		case 2:
 		writeln("You wrote 2");
 		case 3:
 		writeln("You wrote 3");
 		default:
 		writeln("I said: 1 or 2 or 3!");
          }


 and if you want to play with fall through you have to make some
 trick. Again this behaviour of D seems a bit buggy, to me. Are
 there design reasons?
Compile with -w enabled and the compiler will complain about implicit fall-through. You can use goto case/goto default for explicit fall-through.
Jan 19 2012
next sibling parent RenatoL <rexlen gmail.com> writes:
Compile with -w enabled and the compiler will complain about
implicit fall-through. You can use goto case/goto default for explicit fall- through.< This gives a little relief....
Jan 19 2012
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Timon Gehr:

 Compile with -w enabled and the compiler will complain about implicit 
 fall-through.
And eventually this specific -w behavior will be enforced even without -w, becoming part of D2, just like the use of "override". Bye, bearophile
Jan 19 2012
prev sibling next sibling parent reply Derek <ddparnell bigpond.com> writes:
On Fri, 20 Jan 2012 08:55:06 +1100, RenatoL <rexlen gmail.com> wrote:

 Just curious: why in D we are not obligated to use break in every
 branch of a swicth structure?
a) C/C++ compatibility b) Walter likes this construct and uses it in his code. I use a language that enables the coder to choose to use fall through or not. By default, falling through is disabled, so to produce the D effect one can code ... switch i with fallthru do case 1 then writeln("You wrote 1") case 2 then writeln("You wrote 2") case 3 then writeln("You wrote 3") else case then writeln("I said: 1 or 2 or 3!") end switch or alternatively ... switch i do case 1 then writeln("You wrote 1") fallthru case 2 then writeln("You wrote 2") fallthru case 3 then writeln("You wrote 3") fallthru else case then writeln("I said: 1 or 2 or 3!") end switch -- Derek Parnell Melbourne, Australia
Jan 19 2012
parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
== Quote from Derek (ddparnell bigpond.com)'s article
 I use a language that enables the coder to choose to use fall through or
 not. By default, falling through is disabled, so to produce the D effect
 one can code ...
   	switch i do
   		case 1 then
   		writeln("You wrote 1")
   	 fallthru
   		case 2 then
   		writeln("You wrote 2")
   	 fallthru
   		case 3 then
   		writeln("You wrote 3")
   	 fallthru
   		else case then
   		writeln("I said: 1 or 2 or 3!")
          end switch
Personal experience in a program (not a language) is that having certain options on automatically usually is more of an annoyance, than manually turning them on. With that said, having explicit fall through sounds more useful than explicit breaking. However people coming form C and C++, the switch statement changes would be enough to cause their own bugs and perhaps discouragement. The true use in fallthrough, would be if you wanted more than one option to trigger a specific block of code. An example could be with flags, Unix flags have somewhat of a standard, so a program that defined it's own flags may later add secondary flags for compatibility purposes. switch(i) { case 2: case 3: case 5: case 7: printf("%d is a prime between 1 and 10", i); break; default: printf("%d is not a prime between 1 and 10", i); }
Jan 19 2012
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, January 20, 2012 00:38:49 Era Scarecrow wrote:
 Personal experience in a program (not a language) is that having certain
 options on automatically usually is more of an annoyance, than manually
 turning them on. With that said, having explicit fall through sounds more
 useful than explicit breaking. However people coming form C and C++, the
 switch statement changes would be enough to cause their own bugs and
 perhaps discouragement.
The general rule with D is that C/C++ code must either compile as D code and have the same semantics, or it must not compile as D code. There are a few places where that isn't true (e.g. parameters which are static arrays are passed as values in D but not C), but it's fairly rare. So, aside from the fact that it would break lots of D code, making it so that fallthrough was explicit and breaking wasn't wouldn't be acceptable. Not to mention, most programmers would be confused by D's switch if it worked that way, since most languages went with implicit fallthrough (presumably because that's what C did). So, making it explicit for both seems like a good way to go.
 The true use in fallthrough, would be if you wanted more than one option to
 trigger a specific block of code. An example could be with flags, Unix
 flags have somewhat of a standard, so a program that defined it's own flags
 may later add secondary flags for compatibility purposes.
 
 switch(i) {
 case 2:
 case 3:
 case 5:
 case 7:
 printf("%d is a prime between 1 and 10", i);
 break;
 default:
 printf("%d is not a prime between 1 and 10", i);
 }
That actually still triggers implicit fallthrough. -w disallows implicit fallthrough only in cases where a case statement has code in it. - Jonathan M Davis
Jan 19 2012
prev sibling next sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
RenatoL wrote:

 why in D we are not obligated
This depends on how the designer wants the coders to think about the semantics of a <label>. If a <label> _always_ is an _additional_ entry into an otherwise linear sequence of commands, then fall-through as standard is the consequence. If a <label> _always_ breaks the linear sequence of commands, then an implicit `break' as standard is the consequence. Because <label>s outside of `switche's are always additional entries only, one has to specify `case's as not to be <label>s or to have a good reason for the different handling of `label's. So it is up to you to show that `case's are not`label's or give a good reason, if you want a different handling. -manfred
Jan 19 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, January 20, 2012 01:03:21 Matej Nanut wrote:
 I like the error DMD (-w) gives in this situation a lot. It has saved
 me precious minutes of debugging on more than one occasion. :)
 
 And I never liked ‘warning:’s anyway. If something is dangerous enough
 to warrant a warning, the compiler may just as well enforce it in the
 language and be done with it.
That's pretty much Walter's take on it. He doesn't believe in warnings. Either something is an error or it's not. I'm pretty sure that he only added them because of complaints. And when he did, it was with -w - which makes them errors rather than displaying warnings but not preventing compilation as is normal with most compilers. It wasn't until after he got a bunch more complaints that he capitulated and added -wi which then makes dmd act like most compilers on the planet and display warnings without stopping compilation. Personally, I always compile with -w and have increasingly come to agree with Walter's thinking on this. I've long believed that responsible programmers don't commit code with warnings in it. And if warnings are never acceptable, then why are they warnings instead of errors? The only case where I think that warnings can be useful is if it's for something that you know needs to be fixed but which you don't need to fix right away as you're editing code. But considering how many programmers leave warnings in (I've never understood why aside from laziness), having them just creates problems IMHO. IMHO, anything which is definitively a problem should be an error, and anything that _might_ be a problem should be left up to lint-like tools. The only real advantage of -w over having no warnings at this point is that it gives us a way to phase in errors. - Jonathan M Davis
Jan 19 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 19, 2012 at 07:19:07PM -0500, Jonathan M Davis wrote:
[...]
 Personally, I always compile with -w and have increasingly come to
 agree with Walter's thinking on this. I've long believed that
 responsible programmers don't commit code with warnings in it. And if
 warnings are never acceptable, then why are they warnings instead of
 errors? The only case where I think that warnings can be useful is if
 it's for something that you know needs to be fixed but which you don't
 need to fix right away as you're editing code. But considering how
 many programmers leave warnings in (I've never understood why aside
 from laziness), having them just creates problems IMHO.
[...] The root cause of it is probably laziness, or being forced to check in code at 5am for a deadline mandated by things beyond your control. And once this happens, it just perpetuates itself. The poor sods who inherit the initial bad code say, well this code generates warnings, but we don't know what it does and we don't dare to touch it 'cos we don't wanna break stuff that isn't our responsibility in the first place. And then people get used to it: "This project always compiles with warnings, it still works (sortof) so we don't care anymore". Which leads to the sad state that many (most?) commercial projects find themselves in - warnings everywhere and nobody bats an eyelid. I have to say I like Walter's approach. If something is serious enough to be a warning, it should really be an error. The programmer should be made to fix it. If he *wants* to do something dangerous, give him a way to *explicitly* override the error. Potentially dangerous things should never be implicit. The default behaviour should always err on the safe side---as Andrei so poignantly points out in his book. T -- The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- Anonymous
Jan 19 2012