November 26, 2003
"Philippe Mori" <philippe_mori@hotmail.com> wrote in message news:bk7gft$gju$1@digitaldaemon.com...
> We should have also an option to specify that each possible values must have a label for case when all cases must be handled. This would typically be usefull for enumerations where we might want to ensure that all values appears.

A good idea, but this is already addressed in D where the default case, if not specified, is to throw an exception.


November 26, 2003
Walter wrote:
>>We should have also an option to specify that each possible
>>values must have a label for case when all cases must be
>>handled. This would typically be usefull for enumerations
>>where we might want to ensure that all values appears.
> 
> 
> A good idea, but this is already addressed in D where the default case, if
> not specified, is to throw an exception.

Not that I'm against that, but it seems a little inconsistent. What happened to that "we cannot change the semantics of switch because that would confuse C/C++ coders" rule? Throwing an exception where C/C++ would just continue is a rather big difference, isn't it?

If that rule has been dropped - how about adding an implicit break as well? ;)

Hauke

November 26, 2003
> If that rule has been dropped - how about adding an implicit break as well? ;)

Seconded!

C


"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bq2t8k$qe1$1@digitaldaemon.com...
> Walter wrote:
> >>We should have also an option to specify that each possible values must have a label for case when all cases must be handled. This would typically be usefull for enumerations where we might want to ensure that all values appears.
> >
> >
> > A good idea, but this is already addressed in D where the default case,
if
> > not specified, is to throw an exception.
>
> Not that I'm against that, but it seems a little inconsistent. What happened to that "we cannot change the semantics of switch because that would confuse C/C++ coders" rule? Throwing an exception where C/C++ would just continue is a rather big difference, isn't it?
>
> If that rule has been dropped - how about adding an implicit break as well? ;)
>
> Hauke
>


November 26, 2003
> > We should have also an option to specify that each possible values must have a label for case when all cases must be handled. This would typically be usefull for enumerations where we might want to ensure that all values appears.
>
> A good idea, but this is already addressed in D where the default case, if not specified, is to throw an exception.

Wow! That's a *really*, *REALLY* bad idea.

If one is porting some code which very rarely uses the default case - it's largely irrelevant whether that's benign or a bug - it may easily escape the test cases, and "sometime later", in production code, an exception will be thrown which has never been anticipated and therefore never been handled.

This is about the very best/worst example I could possibly think of in the debate between compile-time and runtime error-handling. Rather than causing me 30 seconds in development time, I am up for an unknown, and potentially huge, cost sometime after deployment. Is D really wanting to be a serious systems language?

Yours, in a state of stupefaction

Matthew



November 26, 2003
In article <bq2vi2$tqd$1@digitaldaemon.com>, Matthew Wilson says...
>
>> > We should have also an option to specify that each possible values must have a label for case when all cases must be handled. This would typically be usefull for enumerations where we might want to ensure that all values appears.
>>
>> A good idea, but this is already addressed in D where the default case, if not specified, is to throw an exception.
>
>Wow! That's a *really*, *REALLY* bad idea.

I agree!

Why nobody else is complaining? was this discussed before?

Since the first time I was surprised with the exception
I just automatically type in an empty default.

Ant


November 26, 2003
I havent come accross it, but mark this up as another complaint ! :).

C


"Ant" <Ant_member@pathlink.com> wrote in message news:bq33o3$140q$1@digitaldaemon.com...
> In article <bq2vi2$tqd$1@digitaldaemon.com>, Matthew Wilson says...
> >
> >> > We should have also an option to specify that each possible values must have a label for case when all cases must be handled. This would typically be usefull for enumerations where we might want to ensure that all values appears.
> >>
> >> A good idea, but this is already addressed in D where the default case,
if
> >> not specified, is to throw an exception.
> >
> >Wow! That's a *really*, *REALLY* bad idea.
>
> I agree!
>
> Why nobody else is complaining? was this discussed before?
>
> Since the first time I was surprised with the exception
> I just automatically type in an empty default.
>
> Ant
>
>


November 26, 2003
"Matthew Wilson" <matthew.hat@stlsoft.dot.org> wrote in message news:bq2vi2$tqd$1@digitaldaemon.com...
> > > We should have also an option to specify that each possible values must have a label for case when all cases must be handled. This would typically be usefull for enumerations where we might want to ensure that all values appears.
> >
> > A good idea, but this is already addressed in D where the default case,
if
> > not specified, is to throw an exception.
>
> Wow! That's a *really*, *REALLY* bad idea.

I agree.

Lars Ivar Igesund


November 26, 2003
"Ant" <Ant_member@pathlink.com> wrote in message news:bq33o3$140q$1@digitaldaemon.com...
> In article <bq2vi2$tqd$1@digitaldaemon.com>, Matthew Wilson says...
> >
> >> > We should have also an option to specify that each possible values must have a label for case when all cases must be handled. This would typically be usefull for enumerations where we might want to ensure that all values appears.
> >>
> >> A good idea, but this is already addressed in D where the default case,
if
> >> not specified, is to throw an exception.
> >
> >Wow! That's a *really*, *REALLY* bad idea.
>
> I agree!
>
> Why nobody else is complaining? was this discussed before?
>
> Since the first time I was surprised with the exception
> I just automatically type in an empty default.
>
> Ant

I do that too, and don't like it much. I do, however, like how an exception is thrown if the end of a non-void function is reached.

By the way, I like how switch cases fall through silently; probably for the same reasons as Walter. I proposed that we use a new keyword for cases that automatically break when a new case is found, such as:

switch(s)
{
case 3: falls through
bcase 4: auto-breaks at next case, bcase, or default
}




November 26, 2003
Vathix wrote:
> I do that too, and don't like it much. I do, however, like how an exception
> is thrown if the end of a non-void function is reached.

Huh? How can that happen? Doesn't the compiler check at compile time that there is a return statement in each possible path? All C/C++ compilers I know will at least issue a warning in such a case (though it should be an error). DMD doesn't do that?


Hauke

November 26, 2003
As regards the switch statement, I continue to like the way C# does it; you must either _break_ or _goto_ another case, no fall through, zip, nada, zilch. And the compiler tells you when you try.

<stump>
I would also prefer it be required that the statements in a _case_ be placed in
a block surrounded by braces _{}_ to better group them visually. Same with _if_,
_while_, _for_, _do_ ... anywhere where it is currently required *sometimes*, it
should be required *all the time*. Easier reading, I expect easier
parsing/lexing whatever.

It shouldn't be too difficult to write a script to go through the C code and add
the otherwise extraneous stuff (doesn't hurt the C any) before attempting to
port it.
</stump>