In article <bqe96t$24um$1@digitaldaemon.com>, Walter says...

>Well, that's just what an optimizer is: a code flow analyzer. <g>

I was advocating something different: it makes sense to do this as part of semantic analysis process, and bug user with arbitrary conditions like "i'm not convinced this function returns" or "this switch may not cover a variable value range", as long as convincing the compiler usually takes only one line, which would also make code more explicit. I'm only speaking of my experiance that i found this practice quite convenient. (Delphi fans vote here!)

You must also consider that D advocates a different development cycle than C++. Recompile often and early. In this context it makes sense that the compiler bugs you about something not so important and not the runtime, especally the compiler being so fast.

Your disagreement has probably something to do with your oposition to warnings, since that's what compiler message class this kind of diagnostic could best refer to. You really have to put up a paper on that so that we understand you better.

>Even if all the enum values are accounted for, it's certainly possible the user cast some other value into the enum type.

Should this be legal at all?

If yes, then someone should take responsibility. Eother the cast has to take care that enum only gets a legal value by throwing an exception otherwise, or the programmer...

>Part of my reluctance to do that is implict fallthrough just has never been an issue for me in 25 years of programming. But the implicit default:break; has bitten me many times!

And in the 5 years before the 25 years? You must also consider that you are an exceptional talent and a full-time programmer. I don't value language-specific skills that much...

-eye

"Matthew Wilson" <matthew.hat@stlsoft.dot.org> wrote in message news:bq8cg7$30ro$1@digitaldaemon.com...
> > Why is providing a runtime check that all the bases were covered make a program less robust?
> Anything that pushes out error-detection from (where it is achievable, of course) compile-time to runtime loses robustness. Isn't that axiomatic?

It's not achievable at compile time, regardless of whether the default is inserted by the compiler or the programmer.

> > What really is the essential difference between
> > requiring that the programmer explicitly code a default, and requiring
him
> > to explicitly check array bounds:
> >
> >     if (0 <= i && i < array.length) j = array[i];
> >
> > ?
>
> This is not a valid analogy. Your example is the difference between
checking
> values yourself, or having them checked at runtime. With the
switch/default,
> it is the case of having the options checked at compile time (by requiring all members of an enum to be present), or explicitly telling the compiler that you are aware of/don't care about the default case (with missing
enums,
> or with other types) vs not being "complete" in the code and letting the runtime handle it. They are quite different things.

Yes, but putting a 'default:assert(0);' in is a runtime check, regardless of whether it is coded explicitly or implicitly. Therefore, it is just like an array bounds check.

"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:bqaci5$2rl3$2@digitaldaemon.com...
> Requiring default will bring us to people typing "default: break;" instead of "default: assert(0)"  just exactly for the reason you stated!

A similar problem has happened with Java where it required you to list the possible exceptions generated by each function. Even expert programmers who publicly excoriated the practice would pepper their own code with generic catches just to shut up the compiler. The end result was that a rule that was supposed to increase robustness, actually wound up making things worse.

Philosophically, I don't think a language is robust because it requires programmers to code in a certain way. I think it's robust if it allows programmers to program the way they want to, making robust programming practices easier to use than non-robust ones. For example, although D allows you to use pointers as you would in C, D provides better semantic alternatives (like out parameters) that are more robust, and easier to use than the pointer equivalents. It's a win-win.

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.

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...

I prefer the compiler to tell me about as many bugs as possible while I can still do something about it (at compile time). 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.

Hauke

In article <bqivh7$cr$1@digitaldaemon.com>, Walter says...
>
>
>"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:bqaci5$2rl3$2@digitaldaemon.com...
>> Requiring default will bring us to people typing "default: break;" instead of "default: assert(0)"  just exactly for the reason you stated!
>
>[...]

>Philosophically, I don't think a language is robust because it requires programmers to code in a certain way.

You are contradicting your self because you are forcing programers to have a "defaul:assert(0);". even if they don't know about it!

>[...]

Ant

"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.

In article <bqj778$bkj$1@digitaldaemon.com>, Walter says...
>
>
>"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.
>

You can't convince me on this one ;)
I have nothing to add to mine or Mathew's first posts
on this thread.

Also I never saw you change your mind
so I'm loosing hope on this one.
(reverse psichology. again! but this time no spell check.
didn't work the first time :)

Ant

"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.

"Ant" <Ant_member@pathlink.com> wrote in message news:bqj888$d1r$1@digitaldaemon.com...
> You can't convince me on this one ;)

I'll wait for when it finds an overlooked bug in your code <g>.

"Walter" <walter@digitalmars.com> wrote in message news:bqitol$2va4$1@digitaldaemon.com...
>
> "Matthew Wilson" <matthew.hat@stlsoft.dot.org> wrote in message news:bq8cg7$30ro$1@digitaldaemon.com...
> > > Why is providing a runtime check that all the bases were covered make
a
> > > program less robust?
> > Anything that pushes out error-detection from (where it is achievable,
of
> > course) compile-time to runtime loses robustness. Isn't that axiomatic?
>
> It's not achievable at compile time, regardless of whether the default is inserted by the compiler or the programmer.

Why not?