== 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);
}

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

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