In article <br5jqr$12j4$2@digitaldaemon.com>, Matthew Wilson says...
>
>Interestingly, having an explicit, but empty, default causes most C++ compilers to generate less efficient code

I bet the compiler will add a jump (or branch) to the next
instruction or something like that but with the speculative
execution (or whatever the thing is called)
the impact should be close to 0, well,
even with direct execution the impact is close
to 0, let's see: 1.7 MHz, assuming a short branch takes 4 clock cycles...
I wouldn't mind too much with that, at least for the type of apps I'm writing.

(Maybe I'm completly off, when I give up assembler I stop thinking on these things).

Ant

"Andy Friesen" <andy@ikagames.com> wrote in message news:br7bb7$mgl$1@digitaldaemon.com...
> Ant wrote:
>
> > <joke>
> > [...]
> > </joke>
> >
> > (I guess what I really mean is that every body is saying the
> > same thing over and over again)
> >
> > Ant
>
> The only place I've ever even used switch/case in D is either WndProc, or some similar message enumeration. (SDL, enet, etc)  The "throw on no default" thing has caught me exactly once, and it was an easy fix.
>
> I am stunned beyond description that this issue has raised so much discussion.  What's the big deal? O_o

The reason people are hot under the collar is that the new semantics introduces potential breakages to code that are not predictable. Therefore, if you port any non-trivial apps you cannot, in-principle, be certain that your application is not broken. The only practical measures you have are code coverage testing, and thorough reviews. Anyone who thinks these, or indeed any testing measures, can ever be done to completion needs to read a little Glass ("Facts and Fallacies of Software Engineering").

Given that premise (and if you don't accept it, you either haven't worked on big systems, or have an unreasonable faith in your own abilities beyond that of anyone else in the field, or you are genuinely a genius which the rest of are not), there are two separate issues:

1. If you write new code that is not ported-across-C, then it's arguable that the throw-on-no-default is valid. I certainly would never want to introduce that into a new language, but I accept this is a POV issue.

2. If you are porting C or C++ across, D changes the semantics without warning. Given that, and the complexity issue mentioned above, this means that D is, in-principle, not a suitable language to port C or C++ from.

Since:

a) it's better to detect errors at compile-time, and
b) for D to succeed it has to be able to safely and sensibly port code in
from many other languages, but especially C and C++ (along with Java and
.NET), and
c) I personally want D to succeed a very great deal - I like it, I intend to
contribute several more libraries over the next six months, I want to use it
professionally, I want to write a book about it in the near future - then

I am just dumbfounded that the compile-time option is not the one used.

The only reason I can see for the current implementation is that it is one of Walter's (self-)convenient shortcuts, and the only reason I can think that what seems about 40% of the posters like the current scenario is that (i) they are coming from other languages, and (ii) they don't care about porting from C or C++. Both of these positions are reasonable and respectable; we want people to come to D from all languages. But surely in any situation where a given semantic of the language would please some and confound others, the best approach will always be to make behaviour explicit? When the situation is reversed (I cannot think of an example off-hand) I can assure you I will still be in the make-life-a-teensy-bit-more-difficult-at-compile-time camp, even if it's me to "suffer" in that case.

Cheers

Matthew

In article <br7vc1$1ltd$1@digitaldaemon.com>, Matthew Wilson says...
>
>
>"Andy Friesen" <andy@ikagames.com> wrote in message news:br7bb7$mgl$1@digitaldaemon.com...
>> Ant wrote:
>>
>> > <joke>
>> > [...]
>> > </joke>
>> >
>> > (I guess what I really mean is that every body is saying the
>> > same thing over and over again)
>> >
>> > Ant
>>
>> The only place I've ever even used switch/case in D is either WndProc, or some similar message enumeration. (SDL, enet, etc)  The "throw on no default" thing has caught me exactly once, and it was an easy fix.
>>
>> I am stunned beyond description that this issue has raised so much discussion.  What's the big deal? O_o
>
>The reason people are hot under the collar is that the new semantics introduces potential breakages to code that are not predictable. Therefore, if you port any non-trivial apps you cannot, in-principle, be certain that your application is not broken. The only practical measures you have are code coverage testing, and thorough reviews. Anyone who thinks these, or indeed any testing measures, can ever be done to completion needs to read a little Glass ("Facts and Fallacies of Software Engineering").

No, a release build of the program will have the runtime throw compiled out. If a programmer ports over a switch statement without a default then yes a debug build might unexpectedly break.  The release build will be no different than the original C semantics.

> >>
> >> > <joke>
> >> > [...]
> >> > </joke>
> >> >
> >> > (I guess what I really mean is that every body is saying the
> >> > same thing over and over again)
> >> >
> >> > Ant
> >>
> >> The only place I've ever even used switch/case in D is either WndProc, or some similar message enumeration. (SDL, enet, etc)  The "throw on no default" thing has caught me exactly once, and it was an easy fix.
> >>
> >> I am stunned beyond description that this issue has raised so much discussion.  What's the big deal? O_o
> >
> >The reason people are hot under the collar is that the new semantics introduces potential breakages to code that are not predictable.
Therefore,
> >if you port any non-trivial apps you cannot, in-principle, be certain
that
> >your application is not broken. The only practical measures you have are code coverage testing, and thorough reviews. Anyone who thinks these, or indeed any testing measures, can ever be done to completion needs to read
a
> >little Glass ("Facts and Fallacies of Software Engineering").
>
> No, a release build of the program will have the runtime throw compiled
out.
> If a programmer ports over a switch statement without a default then yes a debug build might unexpectedly break.  The release build will be no different than the original C semantics.

I see. Well that's both good and bad. It's good, because a program will not be broken (in release mode) that should not be broken. It's bad because a program that should be broken will likely not be, since debug testing is very unlikely to provide full coverage (Glass again; OT: I think this is the best software engineering book I've ever read, and heartily commend it to all).

I know half of you think I'm living in cloud cuckoo land, so this'll probably just fly off into the aether, but this situation (compiled out in release) actually adds to the weight of the argument that the default should be mandatory. :(

Cheers

Matthew

| remove   |
| runtime  | Implicit
| throw on | break and|
| missing  | multiple | Mandatory |
| default  | values   | default   |
+----------+----------+-----------+
|    M     |    D     |     D     | SP
+----------+----------+-----------+

Patrick Down wrote:
> In article <br7vc1$1ltd$1@digitaldaemon.com>, Matthew Wilson says...
> 
>>
>>"Andy Friesen" <andy@ikagames.com> wrote in message
>>news:br7bb7$mgl$1@digitaldaemon.com...
>>
>>>Ant wrote:
>>>
>>>
>>>><joke>
>>>>[...]
>>>></joke>
>>>>
>>>>(I guess what I really mean is that every body is saying the
>>>>same thing over and over again)
>>>>
>>>>Ant
>>>
>>>The only place I've ever even used switch/case in D is either WndProc,
>>>or some similar message enumeration. (SDL, enet, etc)  The "throw on no
>>>default" thing has caught me exactly once, and it was an easy fix.
>>>
>>>I am stunned beyond description that this issue has raised so much
>>>discussion.  What's the big deal? O_o
>>
>>The reason people are hot under the collar is that the new semantics
>>introduces potential breakages to code that are not predictable. Therefore,
>>if you port any non-trivial apps you cannot, in-principle, be certain that
>>your application is not broken. The only practical measures you have are
>>code coverage testing, and thorough reviews. Anyone who thinks these, or
>>indeed any testing measures, can ever be done to completion needs to read a
>>little Glass ("Facts and Fallacies of Software Engineering").
> 
> 
> No, a release build of the program will have the runtime throw compiled out.
> If a programmer ports over a switch statement without a default then yes a
> debug build might unexpectedly break.  The release build will be no
> different than the original C semantics.

When I first read this I thought you were recommending compiling in release mode to get rid of the runtime errors instead of adding a "default".  (OK, I realize now that's not what you were suggesting.)

I haven't thought much about debug vs release modes, but it seems absurd the situations that Walter wants to protect us from just fade away into the night when it's compiled in release mode.  That's part of the reason why I think there should either be no error generated at all (my preference) or a compile-time error when a default is missing.

Justin

In article <br86vs$21s4$1@digitaldaemon.com>, Matthew Wilson says...
>
>> >>
>> >> > <joke>
>> >> > [...]
>> >> > </joke>
>> >> >
>> >> > (I guess what I really mean is that every body is saying the
>> >> > same thing over and over again)
>> >> >
>> >> > Ant
>> >>
>> >> The only place I've ever even used switch/case in D is either WndProc, or some similar message enumeration. (SDL, enet, etc)  The "throw on no default" thing has caught me exactly once, and it was an easy fix.
>> >>
>> >> I am stunned beyond description that this issue has raised so much discussion.  What's the big deal? O_o
>> >
>> >The reason people are hot under the collar is that the new semantics introduces potential breakages to code that are not predictable.
>Therefore,
>> >if you port any non-trivial apps you cannot, in-principle, be certain
>that
>> >your application is not broken. The only practical measures you have are code coverage testing, and thorough reviews. Anyone who thinks these, or indeed any testing measures, can ever be done to completion needs to read
>a
>> >little Glass ("Facts and Fallacies of Software Engineering").
>>
>> No, a release build of the program will have the runtime throw compiled
>out.
>> If a programmer ports over a switch statement without a default then yes a debug build might unexpectedly break.  The release build will be no different than the original C semantics.
>
>I see. Well that's both good and bad. It's good, because a program will not be broken (in release mode) that should not be broken. It's bad because a program that should be broken will likely not be, since debug testing is very unlikely to provide full coverage (Glass again; OT: I think this is the best software engineering book I've ever read, and heartily commend it to all).
>
>I know half of you think I'm living in cloud cuckoo land, so this'll probably just fly off into the aether, but this situation (compiled out in release) actually adds to the weight of the argument that the default should be mandatory. :(


Ok lets look at the possibilities here.

Two switch statement types:

S1) All values are ok even if they are not explicitly handled.  default: break;

S2) Only the values handled in the switch statement
are valid.  default: assert(0);

TC - Testing/A value that does not match a case is
given to the switch statement

TN - Testing/A value that does not match a case is
not given to the switch statement

RV - Production version/A value that does not match a case is given to the switch statement


Now lets look at the results of not requiring a default
and then the results of not requiring a default



No default required/programmer forgets the default

S1
==========================================
TC - Exception happens. Programmer puts in:
default break;

TN - No problem all values are ok anyway

RV - No problem all values are ok


S2
==========================================
TC - Exception happens.  Programmer investigates
reason for invalid switch value.  Fixes problem.

TN - Testing misses the error above

RV - The program ends up in some unknown state




Default required

S1
==========================================

TC - No problem all values are ok

TN - No problem all values are ok

RV - No problem all values are ok


S2
==========================================

TC - Exception happens,  Programmer investigates
reason for invalid switch value. Fixes problem.

TN - Testing misses the error above

RV - The program ends up in some unknown state


The end result is mostly the same whether the
default is required or not.

I do understand that by requiring the default you are trying to make the programmer think about the completeness of the case statement.

What book ?

C
"Matthew Wilson" <matthew.hat@stlsoft.dot.org> wrote in message
news:br86vs$21s4$1@digitaldaemon.com...
> > >>
> > >> > <joke>
> > >> > [...]
> > >> > </joke>
> > >> >
> > >> > (I guess what I really mean is that every body is saying the
> > >> > same thing over and over again)
> > >> >
> > >> > Ant
> > >>
> > >> The only place I've ever even used switch/case in D is either
WndProc,
> > >> or some similar message enumeration. (SDL, enet, etc)  The "throw on
no
> > >> default" thing has caught me exactly once, and it was an easy fix.
> > >>
> > >> I am stunned beyond description that this issue has raised so much discussion.  What's the big deal? O_o
> > >
> > >The reason people are hot under the collar is that the new semantics introduces potential breakages to code that are not predictable.
> Therefore,
> > >if you port any non-trivial apps you cannot, in-principle, be certain
> that
> > >your application is not broken. The only practical measures you have
are
> > >code coverage testing, and thorough reviews. Anyone who thinks these,
or
> > >indeed any testing measures, can ever be done to completion needs to
read
> a
> > >little Glass ("Facts and Fallacies of Software Engineering").
> >
> > No, a release build of the program will have the runtime throw compiled
> out.
> > If a programmer ports over a switch statement without a default then yes
a
> > debug build might unexpectedly break.  The release build will be no different than the original C semantics.
>
> I see. Well that's both good and bad. It's good, because a program will
not
> be broken (in release mode) that should not be broken. It's bad because a program that should be broken will likely not be, since debug testing is very unlikely to provide full coverage (Glass again; OT: I think this is
the
> best software engineering book I've ever read, and heartily commend it to all).
>
> I know half of you think I'm living in cloud cuckoo land, so this'll probably just fly off into the aether, but this situation (compiled out in release) actually adds to the weight of the argument that the default
should
> be mandatory. :(
>
> Cheers
>
> Matthew
>
>

> What book ?
>

<snip>

> > > >code coverage testing, and thorough reviews. Anyone who thinks these,
or
> > > >indeed any testing measures, can ever be done to completion needs to
read a
> > > >little Glass ("Facts and Fallacies of Software Engineering").

<snip>

> > very unlikely to provide full coverage (Glass again; OT: I think this is
the
> > best software engineering book I've ever read, and heartily commend it
to all).

In article <br8dmh$2c6n$1@digitaldaemon.com>, J C Calvarese wrote:
>> No, a release build of the program will have the runtime throw compiled out. If a programmer ports over a switch statement without a default then yes a debug build might unexpectedly break.  The release build will be no different than the original C semantics.
> 
> When I first read this I thought you were recommending compiling in release mode to get rid of the runtime errors instead of adding a "default".  (OK, I realize now that's not what you were suggesting.)
>
> I haven't thought much about debug vs release modes, but it seems absurd the situations that Walter wants to protect us from just fade away into the night when it's compiled in release mode.

One of my favourite misused CS quote is from Dijkstra:

"Finally, it is absurd to make elaborate security checks on debugging runs, when no trust is put in the results, and then remove them in production runs, when an erroneous result could be expensive or disastrous. What would we think of a sailing enthusiast who wears his lifejacket when training on dry land, but takes it off as soon as he goes to sea?"

This witty remark is famous because -- it's a witty remark. And sadly often is it so that a witty remark is adopted as a truth and as a basis of a belief.

Now the analogy he makes, like any analogy in general, is an analogy not only because the similarity of the things that are compared, but also because their difference.

And you could counter the argument by saying that sailing and programming are in fact quite different contexts. You might drown while encountering an exceptional situation while sailing and therefore it is expected that anyone in their sane mind would carry all the equipment possible to prevent that.  In programming, however, usually nobody's life is at stake, particularly in one-shot and other non-critical applications.  On the other hand, when lifes _are_ at stake, the amount of care and consideration put into the program more than just leaving the debug statements on.

One must also compare the expected amount of bugs that can be reduced in the process of debugging to the expected amount of risks that can be reduced by training sailing on dry land, and one must compare the processes that are used in order to increase the reliability. And take into consideration the desired level of reliability, and time to achieve it, and the resources available to achieve it. Are the costs that the debug statements lead to tolerable? There must be balance in all things.

Or then again, you could just counterattack with another analogy:

What would we think of a bicycler who uses training wheels while learning to drive the bicycle, but takes them off as soon has he has learned enough to stay in balance?

-Antti