Hauke Duden wrote:

> Patrick Down wrote:
>
>> There are three ways of looking at this.
>>
>> 1) No 'default' means that all other values are an error.  The programmer should explicitly state that other values are not an error condition by putting default: break;
>>
>> 2) No 'default' means that other values are acceptable.
>> The programmer must explicitly state that other values
>> are an error condition by putting default: assert(0);
>>
>> 3) 'No default' is a compiler error.  The programmer must explicitly state how other values are handled. As far as explicitly stating the programmers intention
>> all three work equally well when combined with firm documentation of the default behavior of the switch statement.  All that option 3 really does is save the programmer from an error of omission.  In other words the programmer really intended the opposite behavior from what the default is but forgot to include the 'default' statement.  How is this  any different that any other error of omission?  Are you more likely to forget a 'default' in a 'switch' than a 'else' on a 'if'?
>
>
> There is one important difference: it works differently in all other major languages. I programmed in C, C++ and JAVA for many years and I fear that I WILL forget to put that default in there. D's syntax is so similar in many respects and the construct even has the same name! So this is an accident waiting to happen.
>
> But the worst thing about this is that when that accident happens I might not know it until it is too late (i.e. when the application is shipped and some user has done something that causes the default case to trigger).
>
> That's why I prefer the explicit default. No matter what you think is intuitive (and we have seen that this IS different from person to person), the compiler will warn you right when you made your mistake. Then you just type an additional line and there's no harm done. Compare that to the case where I have to find the bug after a user has told me "Your software thingy crashed! I didn't do anything!".
>
> Hauke

Do you send out distributions that are compiled in debug mode? In release mode an assert won't occur. 

If you have an explicit default, you still don't know if you've missed a case value. All you know is that you've handled all cases, which is a different thing.

Lewis Miller wrote:

>This probably wont help any but a switch that acts like visual basics Select
>Case statement would be the my preferred method.
>Select Case Acts like so:
>
>Select Case Foo
>
>Case 1
>DoSomething()
>
>Case 2,3,4,5
>DoSomething()
>
>Case 10
>DoSomething()
>
>Case Else
>Nothing Was Caught So Do A Default
>
>End Select
>
>What happens, is that it falls down thru till a match is found, an that matching
>statement is then executed... if nothing is found, the Case Else is excecuted.
>The Case Else is optional, so if nothing is matched, nothing is excecuted.
>
>  
>
This is my preference as well.  I guess the D version would look slightly different, but it's the general idea that counts.

The Lone Harnguer wrote:

>Uh uh uh...
>
>The compiler _does_ require good practices (in your opinion) or, in my opinion,
>bad practices in some cases.
>
>e.g.
>if ( x = y )
>which is flagged by the compiler and needs to have more code added to tell the
>compiler that that is what I meant -- _that's bad_ !
>
>And, even worse, it breaks ported C code as well.
>  
>
If C code porting was 100% supported by D, then we'd be back to C++.  D need to break some C rules inorder to be better.
IMHO An error message for if ( x = y ) is a good start, and it isn't to hard to fix.  Hay, you can even find replace most of these with a good find-replace program.

-Anderson

J C Calvarese wrote:
> Lewis Miller wrote:
> 
>> This probably wont help any but a switch that acts like visual basics Select
>> Case statement would be the my preferred method.
>> Select Case Acts like so:
>>
>> Select Case Foo
>>
>> Case 1
>> DoSomething()
>>
>> Case 2,3,4,5
>> DoSomething()
>>
>> Case 10
>> DoSomething()
>>
>> Case Else
>> Nothing Was Caught So Do A Default
>>
>> End Select
>>
>> What happens, is that it falls down thru till a match is found, an that matching
>> statement is then executed... if nothing is found, the Case Else is excecuted.
>> The Case Else is optional, so if nothing is matched, nothing is excecuted.
>>
>>
> This is my preferred style as well.  (Maybe it's from all of my experience in VB/VBA.)
> 
> It handles the cases I ask it to handle.  That's enough for me.
> 
> Justin

interestingly enough, vb also has a switch statement

i.e
i = Switch( Index , 1, 2, 3, 4, 5)

Following that, i would say that it would be best to keep switch close to what it is, and add a new keyword (such as branch() i like) for a advanced switch statement

Me too, I do not like that "break"'s in the switch.
But I understand the others.
Maybe Walter should add also a "branch" statement, where the rules are similar
to Pascal's "case": no breaks (or the break should be implicit), "ranged" cases
(i.e. case 1..8) etc. To meet all tastes...



In article <br5ni9$189d$1@digitaldaemon.com>, Dan Liebgold says...
>
>In article <br5b9g$l4b$1@digitaldaemon.com>, Lewis Miller says...
>>
>>This probably wont help any but a switch that acts like visual basics Select
>>Case statement would be the my preferred method.
>>Select Case Acts like so:
>>
>>Select Case Foo
>>
>>Case 1
>>DoSomething()
>>
>>Case 2,3,4,5
>>DoSomething()
>>
>>Case 10
>>DoSomething()
>>
>>Case Else
>>Nothing Was Caught So Do A Default
>>
>>End Select
>>
>>What happens, is that it falls down thru till a match is found, an that matching statement is then executed... if nothing is found, the Case Else is excecuted. The Case Else is optional, so if nothing is matched, nothing is excecuted.
>>
>>
>
>I must agree with this approach.  This, to my mind, is the right way (TM) to do
>switches/cases/selects.  The C'ish approach smacks of hackery and danger
>(dangery?  hackanger?).
>
>I've been working in a language other than C/C++ for ~2 years now professionally (game development, native code compiled language), and while it does resemble C++ in many ways, it implements switches as above.  I must say I don't miss C's questionable switches *at all*. They seem quite bad to my mind, and I'm glad to have moved away from them.
>
>(hmm... what's this dead horse doing here?)
>
>Fall-through is bad! You never *ever* need it. If you reexamine all your switch statements in your own code and think of how they'd be done if fall-through were not allowed, I believe you will find that you could write clearer code once you've made the paradigm shift. Fall-through's are treacherous short-cuts and are bugs waiting to happen. They do not belong in a language that is attempting to increase code safety.
>
>The reuse of the 'break' keyword is confusing at best, and significantly dangerous at worse (see http://www.cs.berkeley.edu/~nikitab/courses/cs294-8/hw1.html for an example where a programmer expected the 'break' in a 'switch' to break out of an enclosing loop, causing a telephone system failure that ran up a $60 million loss).  'Break' should mean only one thing!   Switch statements cases should break implicitly. Cases should be stackable as above to account for handling multiple cases exactly the same way.  Goto's, explicit fall-throughs, and other sleights of hand are extra.  C# is blazing the way, we must merely follow.
>
>(I bet that dead horse will think twice next time!)
>
>As for requiring a 'default' case, I think that is an extreme response to a specific problem.  It really looks no different (to my eyes) than requiring an 'else' for every 'if'.
>
>Throwing an exception when a case isn't handled *will* force programmers to write safer code in general, but the cost is not insignificant.  I can see both sides of this issue so I'll defer to Walter for the force of the argument.
>
>There, I've had my rant  :)
>
>Dan L.
>
>

J Anderson wrote:
> Do you send out distributions that are compiled in debug mode? In release mode an assert won't occur.

Problem is, D doesn't do an assert, it throws an exception (SwitchException, if I recall it correctly). Walter just wrote default;assert(0); "metaphorically" in this discussion (he said so somewhere himself).

Hauke

"Walter" <walter@digitalmars.com> wrote in message news:br3s0v$19rs$2@digitaldaemon.com...
>
 (..)
> Casting, unions, pointers, reading data from files, inline assembler, external functions, buffer overflows overwriting the stack with a
virus(!),
> etc. All kinds of ways to have random bit patterns in an otherwise constrained repository for a type. Just the kinds of problems DbC should help catch <g>.
>

I though this will throw an IllegalCastException or something like that but it doesn't:

enum SomeEnum {cero, uno, dos, tres};

void main()
{
    SomeEnum se = cast(SomeEnum)10;
    printf("%d\n", se);
}

Shouldn't the cast line had a runtime check? Just asking.

Hauke Duden <H.NS.Duden@gmx.net> wrote in news:br6oio$2pf2$1 @digitaldaemon.com:

> J Anderson wrote:
>> Do you send out distributions that are compiled in debug mode? In release mode an assert won't occur.
> 
> Problem is, D doesn't do an assert, it throws an exception (SwitchException, if I recall it correctly). Walter just wrote default;assert(0); "metaphorically" in this discussion (he said so somewhere himself).


Actaully these execptions are compliled out in the release version, just like the array bounds checking. ( Walter correct me if I'm wrong. )

I still don't think that the compiler should spend its time checking for poor or perhaps-mistake-ridden code. That should be a job for some other utility. The compiler should merely compile what its given, only confirming that the code is legal. It seems hypocritical to me that you want to fill up the compiler with all sorts of bloat and then complain that builds take too long.

<And, yes, I'm talking about your  if (x = y )  being illegal bit of nonsense.>

A file doesn't need to be checked for rookie mistakes every time it's compiled, only when it's changed. If we write and check a file and then put it into a code library, why check it again when it's pulled out for inclusion in a new project?

If D is to be for beginners, then OK, put training wheels on it. But if it's to be for experienced power programmers who write expressively and perhaps obfuscatedly (?), then trust us to know what we're doing!

Or maybe add an /expert or /fast switch to the command line, or have /release not check such things?


In article <Xns944D595474DC9patcodemooncom@63.105.9.61>, Patrick Down says...
>
>Hauke Duden <H.NS.Duden@gmx.net> wrote in news:br6oio$2pf2$1 @digitaldaemon.com:
>
>> J Anderson wrote:
>>> Do you send out distributions that are compiled in debug mode? In release mode an assert won't occur.
>> 
>> Problem is, D doesn't do an assert, it throws an exception (SwitchException, if I recall it correctly). Walter just wrote default;assert(0); "metaphorically" in this discussion (he said so somewhere himself).
>
>
>Actaully these execptions are compliled out in the release version, just like the array bounds checking. ( Walter correct me if I'm wrong. )

Patrick Down wrote:

>Hauke Duden <H.NS.Duden@gmx.net> wrote in news:br6oio$2pf2$1
>@digitaldaemon.com:
>
>  
>
>>J Anderson wrote:
>>    
>>
>>>Do you send out distributions that are compiled in debug mode? In release mode an assert won't occur.
>>>      
>>>
>>Problem is, D doesn't do an assert, it throws an exception (SwitchException, if I recall it correctly). Walter just wrote default;assert(0); "metaphorically" in this discussion (he said so somewhere himself).
>>    
>>
>
>
>Actaully these execptions are compliled out in the release version,
>just like the array bounds checking. ( Walter correct me if I'm wrong. )
>  
>
That is what I ment.