"Walter" <walter@digitalmars.com> wrote in message news:bqj778$bkj$1@digitaldaemon.com...
>
> "Ant" <Ant_member@pathlink.com> wrote in message news:bqj3b0$5vc$1@digitaldaemon.com...
> > You are contradicting your self because you are forcing programers to have a "defaul:assert(0);". even if they don't know about it!
>
> But D doesn't force them to explicitly write it! Sorry if I wasn't clear about that.

So what? It does force them to have it.

This is so bogus. You are forcing something on people that probably a lot of them do not want. How is that in keeping with the philosophy of not forcing things on people?

Which is more odious, a forced compile-time restriction, or a forced runtime restriction?

"Walter" <walter@digitalmars.com> wrote in message news:bqjanc$gfp$1@digitaldaemon.com...
>
> "Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bqj2ca$4lq$1@digitaldaemon.com...
> > Walter wrote:
> > > One can counter this by saying "why do static type checking at all,
> then?
> > > Why not do it at runtime?" It's an excellent point, and the answer is
> that
> > > it's just too expensive to do at runtime. Languages that rely on
runtime
> > > type checking tend to run very slowly compared with statically typed languages. As always, everything is a compromise in programming, and
so
> we
> > > have static type checking in D.
> > You'd prefer runtime type checking to compile time type checking? Urrrgh! I think we are very different types of programmers...
>
> No, that's not what I meant. Certainly, the earlier errors can be
detected,
> the better, and compile time is the earliest. The compiler should do as
much
> as it can, and runtime checks inserted to cover what it cannot.
>
> > I prefer the compiler to tell me about as many bugs as possible while I can still do something about it (at compile time).
>
> Yes, you are correct.
>
> > If all the checks
> > happen at runtime, chances are that some of these bugs will not be
> > discovered until it's too late - i.e. when the program is shipped and a
> > customer has run the program in a way that triggered some condition that
> > was not tested.
>
> You're right. But I'd also prefer a runtime that generated an exception on an untested unanticipated condition, rather than fall through to some essentially random default behavior, which is what happens with C's
implicit
> switch default behavior.
>
> It's very, very important that programs fail in a controlled manner when they encounter unanticipated conditions.

Ok, I can (hopefully) see where you're not understanding our argument. AFAICT no-one's arguing for a C status-quo, which is what all your arguments seem to be addressing. Put in its simplest form: we want the compiler to force us to write a default, *in all cases*. My previous suggestion was to enable the syntactic sugar of substituting "unexpected:" for "default: assert(0);". (Note that "unexpected:" would throw something a little more informative than assert(0), perhaps an UnexpectedCaseException?)

Walter wrote:
> It's very, very important that programs fail in a controlled manner when
> they encounter unanticipated conditions.

Nondeterministic bugs are great for burning a few hours (and brain cells)

 -- andy

"Walter" <walter@digitalmars.com> wrote in message news:bqjanc$gfp$1@digitaldaemon.com...
>
> It's very, very important that programs fail in a controlled manner when they encounter unanticipated conditions.
>

I might accept your solution if you make a minor change. Don't use
assert(0);!
As a programmer I might sprinkle asserts in my code and when I
do, I know that some of my code (or at least the user of my code)
has made a mistake and I might start to look for the assert in question.
But suddenly I get an assert exception that don't match an assert in
my code! Can be nothing else than an compiler bug. And I suppose
I will flag it as such if it ever happens to me.
The exception thrown MUST be a well documented and well
specified exception (like the UnknownSwitchCaseException suggested
by Matthew).

Even better, demand the default case at compile time. Then it will never be a problem at runtime!

Lars Ivar Igesund

I may be not getting this argument.
I see Water saying:
You can have a default case if you want to, it may do nothing.
The normal default case will throw an exception.

Others are saying:
Let the default case be do nothing (like C/C++).  And it's up to the programmer to explicity decide if the default case is an error.

Personally I like the default exception method, it will catch bugs.  But I can see how porting legacy code directly from C would possibly allow different kinds of bugs to slip through.
Why not have a compiler switch that can enforce the requirement for a default case - then everyone wins.  Those that like the fall through behaviour will get compile time errors & be forced to place empty default cases, those that like the default exception method can have that too.
At the end of the day it's a programmer preference.

Brad

Lars Ivar Igesund wrote:
> "Walter" <walter@digitalmars.com> wrote in message
> news:bqjanc$gfp$1@digitaldaemon.com...
> 
>>It's very, very important that programs fail in a controlled manner when
>>they encounter unanticipated conditions.
>>
> 
> 
> I might accept your solution if you make a minor change. Don't use
> assert(0);!
> As a programmer I might sprinkle asserts in my code and when I
> do, I know that some of my code (or at least the user of my code)
> has made a mistake and I might start to look for the assert in question.
> But suddenly I get an assert exception that don't match an assert in
> my code! Can be nothing else than an compiler bug. And I suppose
> I will flag it as such if it ever happens to me.
> The exception thrown MUST be a well documented and well
> specified exception (like the UnknownSwitchCaseException suggested
> by Matthew).
> 
> Even better, demand the default case at compile time. Then it will
> never be a problem at runtime!
> 
> Lars Ivar Igesund
> 
> 

> > It's very, very important that programs fail in a controlled manner when they encounter unanticipated conditions.
> >
>
> I might accept your solution if you make a minor change. Don't use
> assert(0);!
> As a programmer I might sprinkle asserts in my code and when I
> do, I know that some of my code (or at least the user of my code)
> has made a mistake and I might start to look for the assert in question.
> But suddenly I get an assert exception that don't match an assert in
> my code! Can be nothing else than an compiler bug. And I suppose
> I will flag it as such if it ever happens to me.
> The exception thrown MUST be a well documented and well
> specified exception (like the UnknownSwitchCaseException suggested
> by Matthew).
>
> Even better, demand the default case at compile time. Then it will never be a problem at runtime!

Exactly. What could be simpler?

> I may be not getting this argument.
> I see Water saying:
> You can have a default case if you want to, it may do nothing.
> The normal default case will throw an exception.
>
> Others are saying:
> Let the default case be do nothing (like C/C++).  And it's up to the
> programmer to explicity decide if the default case is an error.

That is not so. We're saying that the default must be specified.

The logic is simple:

1. Omitting "default" can be problematic
2. Having default behaviour, that throws an exception, when "default" is
ommitted can be problematic
3. Requiring default (or unexpected) be specified costs nothing but fewer
maintenance keystrokes.

As the yanks like to say: you do the math!

> Personally I like the default exception method, it will catch bugs.

This is wrong. It will catch _some_ bugs, not all. Only mandatory default will catch all (unless the programmer is a f-wit, in which case ...)

>  But
> I can see how porting legacy code directly from C would possibly allow
> different kinds of bugs to slip through.

Not if it was mandatory

> Why not have a compiler switch that can enforce the requirement for a default case - then everyone wins.

Walter won't have warnings, and wants to minimise the number of compilation modes. I agree with this.

Given that stipulation, the clear position is to make the default (or
unexpected) mandatory

I've gone through reams of C code, and I am not convinced anymore about the break statement. It really seems like the vast majority of code does not need fallthrough, most of the switches are full of breaks. Actually, cases without break (ie they fall through to the next case) are much rarer than I originally thought. (Maybe textbooks overrepresent examples of this?)

All fallthrough cases I found were empty themselves, so situations where there's some code in one case after which the code of the next is executed did not exist in my data. (Open Source from my Linux distro, a pseudorandom sample about 2.5M of c.)

This really blew my previous conviction. So, now I jump into the "no break means break, fallthrough needs an explicit statement" gang.

If we think near the metal, then the old break thing seems natural,
but what we are aiming at is a higher level language here, so
we gotta think outside the metal. Implicit break (heh, saves ink,)
gives clearer code, and I admit, now seems to be less dangerous
than demanding explicit break.

Since the cases where you need fallthroug are comparatively rare, you sort of notice them, and there it is natural to have to write a word more.

This change also suggests that we should allow lists in cases. This
would also make it even rarer to need fallthrough.
Actually, we might consider skipping fallthrough totally.
The situations where you'd use it could be refactored, and we could
leave the optimizing to the optimizer. (Or if you insist on living
dangerously you could use (ohmigawd!) goto.)

This warns me of another thing: earlier I pointed out that not being able to touch type should not influence our decisions about the language. Similarly, ingrained coding habits, our pet idioms, and "thinking in Pascal when writing Java"  -- shouldn't either influence our current thinking about D!

In Java we are used to the language runtime issuing exceptions for
things that are out of the ordinary, such as: NullPointerException,
ClassCastException, IndexOutOfBoundsException, etc.

The use of the "assert(0)" as the default "default" clause is not
really my beef.  What I really want is to know exactly where the
error happened.  I can't know that if all I get is "Assertion Error"
from the application.  I need a stack trace to find out where this
assertion happened.  What would be even better is to use a better
typed exception like this:

default: throw new UnexpectedCaseException(caseValue);

That way we can output the caseValue, an exception that makes sense.
But even more important some very basic debug info like where the
stinkin' exception was thrown is imperitive.

Imagine having an application that has 100 switch statements, and
they encounter this unexpected case with the default: assert(0) semantics.
Debugging is a nightmare!  Where to look?  Which one of these 100 switch
statements is the culprit?  If it was the culprit, what was the value
that caused the exception?

These are very important pieces of information that I think would be
more reasonable than a simple assert(0).

[warning: some of you might not find this idea appealing.]

It was suggested before, and now I'd like to bring it up again. I don't think Walter will change the way switch works. Maybe he'll change the default: status, but fallthrough will remain, and that's because he wants some kind of C compatibility. (OT: btw, I don't agree with this. It's been said many times, and I repeat: people shouldn't just copy and paste C code for their D programs).

So maybe the next logical thing would be to add a different kind of switch with all the things we all (by majority) have asked for: fallthrough, explicit default, ranges, multiple case values, etc. What the keyword might be, I don't know. Maybe Basic's select would fit.

————————————————————————— Carlos Santander


---

Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.545 / Virus Database: 339 - Release Date: 2003-11-27