"Unknown W. Brackets" <unknown@at.simplemachines.dot.org> wrote in message news:c6774l$op$3@digitaldaemon.com...
> J C Calvarese wrote:
>
> > No flame war from me, but I'd prefer a compile-time "lack of default" error to the present run-time error for an unmatched case. (I was one of the unhappy participants the last time we had a big discussion on this, and I'm still not satisfied.)
>
> But what about when you don't need a default, because it's only going to be either 0 or 1?  *Forcing* a default is not, in my opinion, something I would prefer my compiler to do.  Maybe it could be an option.

We don't do options in D.

What's so hard about adding one in? Maintenance is the vastly dominant activity in software engineering, so why do you care about the initial "cost" in your time, if you're going to save far more in the future?

> Personally, I think a runtime error fits just fine because you can't know if it will be outside or not until it actually runs.

That's a furphy. What's it being "outside or not" got to do with whether or not you write appropriate code?

> Perhaps it could be a warning though?

We don't do warnings in D.

deja vu (+ some accents)

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c677g8$1q1$3@digitaldaemon.com...
> Unknown W. Brackets wrote:
>
> >
> > But what about when you don't need a default, because it's only going
> > to be either 0 or 1?  *Forcing* a default is not, in my opinion,
> > something I would prefer my compiler to do.  Maybe it could be an option.
> >
> > Personally, I think a runtime error fits just fine because you can't know if it will be outside or not until it actually runs.
> >
> > Perhaps it could be a warning though?
> >
> > -[Unknown]
>
>
> Day-shar-voo (how do you spell it?).  Anyway the matrix must be changing
> something....
>
> -- 
> -Anderson: http://badmama.com.au/~anderson/

Derek Parnell wrote:

> Ok, so its a matter of timing (and thus who is told of the situation).
>
>Whether the situation is raised at compile-time or at run-time. Obviously
>the compiler already knows of it as it has to insert the exception throwing
>code, so I guess the earliest point is at compile-time. I guess this would
>be better because then the developer finds out about it before the customer
>using their application.
>  
>
As a design practice, in C++ Walter put the exception in as well,  D just does this automaticly for him.

I've a feeling we're going to hear all same 125 different points of view yet again :(

Parhaps someone should summarise what was said last time.  *Me* oh no, I'm no good at that kinda thing.

Dam it, I just answered this thread.

-- 
-Anderson: http://badmama.com.au/~anderson/

Matthew wrote:

> That's a furphy. What's it being "outside or not" got to do with whether or not
> you write appropriate code?

I solve that problem by generally avoiding switches when there are small cases, and not using them if I don't know exactly what the variable could be.

But having to add a default: to a switch with two items just seems... so very trivial to me.  It also presents a barrier to people learning D, because this is not something you expect with *general* C syntax imho.

-[Unknown]

"Unknown W. Brackets" <unknown@at.simplemachines.dot.org> wrote in message news:c678e1$3ba$2@digitaldaemon.com...
> Matthew wrote:
>
> > That's a furphy. What's it being "outside or not" got to do with whether or
not
> > you write appropriate code?
>
> I solve that problem by generally avoiding switches when there are small cases, and not using them if I don't know exactly what the variable could be.
>
> But having to add a default: to a switch with two items just seems... so very trivial to me.  It also presents a barrier to people learning D, because this is not something you expect with *general* C syntax imho.

If you've only got two cases, why not use if / ?: ?

Anyway, whether or not it is a barrier to newbies is, again, a furphy. It is far worse to have surprising and unpredictable runtime behaviour than to give a specious usability to the odd newcomer to the language. As soon as they get experience they'll learn to hate the silent default exception. ("They will if they've any sense, anyway", spake the Dr contentiously <g>)

Darn; I really didn't mean to stir this one up again :-{

Since we're here though, I'll dip my oar in the water: if someone can come up with a way where the compiler would happily accept the quick porting of C-like code *without* an explicit "default:" then I think the compile-time versus runtime debate would end with the compile-time error winning out. In other words, I imagine there's a backward compatibility factor involved here. IMHO, the compiler currently provides backward compatibility via the runtime approach instead.

One way to resolve this would be to provide a (*gulp*), another compiler
switch ...

- Kris

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c678i6$4dg$1@digitaldaemon.com...
>
> "Unknown W. Brackets" <unknown@at.simplemachines.dot.org> wrote in message news:c678e1$3ba$2@digitaldaemon.com...
> > Matthew wrote:
> >
> > > That's a furphy. What's it being "outside or not" got to do with
whether or
> not
> > > you write appropriate code?
> >
> > I solve that problem by generally avoiding switches when there are small cases, and not using them if I don't know exactly what the variable could be.
> >
> > But having to add a default: to a switch with two items just seems... so very trivial to me.  It also presents a barrier to people learning D, because this is not something you expect with *general* C syntax imho.
>
> If you've only got two cases, why not use if / ?: ?
>
> Anyway, whether or not it is a barrier to newbies is, again, a furphy. It
is far
> worse to have surprising and unpredictable runtime behaviour than to give
a
> specious usability to the odd newcomer to the language. As soon as they
get
> experience they'll learn to hate the silent default exception. ("They will
if
> they've any sense, anyway", spake the Dr contentiously <g>)
>
>

Once again I must state my opinion that if D is to be "better" than C, it can not be centered around "easy porting" and backward compatibility.

>up with a way where the compiler would happily accept the quick porting of C-like code *without* an explicit "default:" then I think the compile-time

And such a thing should be caught by something like LINT before it ever gets to the compiler anyway.

But then, it is my opinion that there is too much other LINT-like functionality bloating the compiler as well.

James Widman wrote:

<snip>
> Well, it does seem consistent with the language's design philosophy that the sooner you learn about a bug (or potential bug), the better.

While inconsistent with another of the language's design philosophies, namely that code that looks like C should act like C.

OTOH, the other thing about switch (default fall-through) is keeping with the second philosophy while dodging the first.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

"James Widman" <james@jwidman.com> wrote in message news:james-5E8BAF.20504221042004@digitalmars.com...
> Erm...hope this doesn't start a flame war. :-)

LOL. This is probably the most debated topic in this newsgroup!