Jump to page: 1 2
Thread overview
Switch and break
Jan 19, 2012
RenatoL
Jan 19, 2012
Peter Alexander
Jan 19, 2012
Jonathan M Davis
Jan 20, 2012
Matej Nanut
Jan 19, 2012
Timon Gehr
Jan 19, 2012
RenatoL
Jan 19, 2012
bearophile
Jan 19, 2012
Derek
Jan 20, 2012
Era Scarecrow
Jan 20, 2012
Jonathan M Davis
Jan 19, 2012
Manfred Nowak
Jan 20, 2012
Jonathan M Davis
Jan 20, 2012
H. S. Teoh
January 19, 2012
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!");
        }

is good in D, while, for example, similar code in C# is incorrect 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?
January 19, 2012
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!");
>          }
>
> is good in D, while, for example, similar code in C# is incorrect
> 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.

January 19, 2012
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!");
>          }
>
> is good in D, while, for example, similar code in C# is incorrect
> 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.
January 19, 2012
>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....
January 19, 2012
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
January 19, 2012
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
January 19, 2012
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

January 19, 2012
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
January 20, 2012
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-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

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.

Matej
January 20, 2012
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
« First   ‹ Prev
1 2