This might make everyone happy:

- Have switch act exactly like C's switch; no implicit exception for the
default case. This allows you to port C code easier. People who like C's
switch may continue to use it.

- Add a new branch construct that has our new ideas. select is a good name
too but there's a common C function with that name. Maybe like this:

branch(val)
{
   case(3) { }
   case(2, 4) { }
   case(5 .. 8) { }
   default { }
}

The default might not need to implicitly throw an exception because the
cases won't fall through.


Is this a good solution?  Everyone want a copy of my victory music tape? :+P

Vathix wrote:
> This might make everyone happy:
> 
>  - Have switch act exactly like C's switch; no implicit exception for the
> default case. This allows you to port C code easier. People who like C's
> switch may continue to use it.
> 
>  - Add a new branch construct that has our new ideas. select is a good name
> too but there's a common C function with that name. Maybe like this:

Or, if Walter doesn't want to add a completely new construct, how about 
"switchall" for a switch that is intended to cover all cases? Let that 
one throw the exception, and have the normal "switch" behave in the way 
most of us are used to.

Hauke

I agree.

In article <br6ke3$2j1b$1@digitaldaemon.com>, Vathix says...
>
>This might make everyone happy:
>
> - Have switch act exactly like C's switch; no implicit exception for the
>default case. This allows you to port C code easier. People who like C's
>switch may continue to use it.
>
> - Add a new branch construct that has our new ideas. select is a good name
>too but there's a common C function with that name. Maybe like this:
>
>branch(val)
>{
>    case(3) { }
>    case(2, 4) { }
>    case(5 .. 8) { }
>    default { }
>}
>
>The default might not need to implicitly throw an exception because the
>cases won't fall through.
>
>
>Is this a good solution?  Everyone want a copy of my victory music tape? :+P
>
>
>
>

> The default might not need to implicitly throw an exception because the
> cases won't fall through.

Actually, this doesn't have much to do with it so maybe it should throw one.
Also, I don't think break should leave the branch; it would be for an
enclosing loop or switch.

Vathix says...
>branch(val)
>{
>    case(3) { }
>    case(2, 4) { }
>    case(5 .. 8) { }
>    default { }
>}

Hmm.  It's a Ruby-like branch statement!
In Ruby, it is as:

case(val)
when 3
..
when 2, 4
..
when 5 .. 8
..
else
..
end

and of course it doesn't fall through.
(This code is exactly equivalent to your code.)
Though I've sometimes wanted to fall through in Ruby,
I think, nested functions will solve the problem in D.

I'm familiar with this type of branch statement and I would like it.

Robert (Japanese)

Vathix wrote:
> This might make everyone happy:
> 
>  - Have switch act exactly like C's switch; no implicit exception for the
> default case. This allows you to port C code easier. People who like C's
> switch may continue to use it.

Disagree strongly. Current D switch places no portability problems, 
since the imcopatibility is easy to track visually - and a code review 
is requiered when porting anyway, because array semantics is different.

Even if gone unnoticed when reviewing, the oversight manifestates itself 
in a totally clear manner on the very first run.

>  - Add a new branch construct that has our new ideas. select is a good name
> too but there's a common C function with that name. Maybe like this:

New name is not the C/C++/D way. C and C++ have a long tradition of 
using modifiers to identifiers. Maybe something like "safe switch" or 
"break switch" or "auto switch"? The last 2 don't add anything to lexer. 
I vote for the last one.

-eye

In article <br6ke3$2j1b$1@digitaldaemon.com>, Vathix wrote:
> This might make everyone happy:

Only the thought of making everyone happy makes me feel unhappy.

For some reason I believe that having several alternatives that almost
do the same thing but differ in small ways, even only syntactically, is
not the right thing to do.

It makes language feel clumsy and more difficult for learn. Witness C++,
which has both pointer and reference types which are almost the same
thing with different syntax. (Which leads us to an amusing sidetrack:
the Microsoft guys are actually adding a new reference type, handles, to
managed C++. The horror! See
http://blogs.gotdotnet.com/branbray/default.aspx?date=2003-11-17 and
http://blogs.gotdotnet.com/slippman/default.aspx?date=2003-12-02)

Or look at the fact that C++ has struct and class, which are the same
thing except that the other has public members by default and the other
has private. So which one should I use? Reasons of this are probably
complicated; partly the situation is as it is because they wanted to
keep C programmers happy, so structs had to work as they do in C, and
classes were also meant to lightweight abstractions, so the notions were
combined.

Another bad example of trying to provide everything for everyone are fat
interfaces.

So "making everyone happy" is bad.  Unless, of course, the old way
exists for the sole purpose of making existing C code run and is
otherwise non-recommended. Which is what D is currently doing by
allowing both "int[] x;" and "int x[];", at least I would imagine so.
Maybe seasoned C hackers are occasionally allowed to use the latter, but
I certainly wouldn't use it ;)

Fortunately, D has a different user base than C++ had when it was on the
drawing board. So there is, I believe, more room for improvements that
will break existing C code. (Of which there is not much, I assume?) Why
not change the semantics of switch statement completely? D has already
set its foot on that path by adding the implicit "default: assert(0);"

-Antti

Yes, but I don't see a need for the parentheses around the switch expression and
case values. (You did mean to say that the braces are required, right?

In article <br6ke3$2j1b$1@digitaldaemon.com>, Vathix says...
>
>This might make everyone happy:
>
> - Have switch act exactly like C's switch; no implicit exception for the
>default case. This allows you to port C code easier. People who like C's
>switch may continue to use it.
>
> - Add a new branch construct that has our new ideas. select is a good name
>too but there's a common C function with that name. Maybe like this:
>
>branch(val)
>{
>    case(3) { }
>    case(2, 4) { }
>    case(5 .. 8) { }
>    default { }
>}
>
>The default might not need to implicitly throw an exception because the
>cases won't fall through.
>
>
>Is this a good solution?  Everyone want a copy of my victory music tape? :+P
>
>
>
>

Vathix wrote:

>This might make everyone happy:
>
> - Have switch act exactly like C's switch; no implicit exception for the
>default case. This allows you to port C code easier. People who like C's
>switch may continue to use it.
>
> - Add a new branch construct that has our new ideas. select is a good name
>too but there's a common C function with that name. Maybe like this:
>
>branch(val)
>{
>    case(3) { }
>    case(2, 4) { }
>    case(5 .. 8) { }
>    default { }
>}
>
>The default might not need to implicitly throw an exception because the
>cases won't fall through.
>
>
>Is this a good solution?  Everyone want a copy of my victory music tape? :+P
>
>
>  
>
Parhaps instead of a whole new construct. One key word could be added 
(I'm using when, but it could be anything)..

case (val)
{
when 5 : //when's have no fall through
case 5: //C style case
break; //C style break
default : //D style (or C style)
}

Both when and case would support ranges, and lists.  As to the run-time 
default, this would not solve the handle-all-cases argument.  It would 
help with the fall though issue though.

Alternatively (even less changes), for no fall-though drop the : and add 
a { }. I dropped the : to make portability easy.
ie
case (val)
{
case 5 {} //no fall through
case 5: //C style case
break; //C style break
default: //D style (or C style)
}

Ilya Minkov wrote:
> Vathix wrote:
> 
>> This might make everyone happy:
>>
>>  - Have switch act exactly like C's switch; no implicit exception for the
>> default case. This allows you to port C code easier. People who like C's
>> switch may continue to use it.
> 
> 
> Disagree strongly. Current D switch places no portability problems, 
> since the imcopatibility is easy to track visually - and a code review 
> is requiered when porting anyway, because array semantics is different.
> 
> Even if gone unnoticed when reviewing, the oversight manifestates itself 
> in a totally clear manner on the very first run.

Huh? That's what this whole discussion is all about! If the error would 
occur on the very first run, then it would never be more than a small 
annoyance - no big deal.

But it doesn't always happen at the first run. Not even necessarily in 
ANY of your test runs. Test cases can rarely cover all code paths, so 
that exception may never be thrown in your testing. It may still crash 
for the end user, though - which is bad!

I could be happy with almost any solution that would trigger the error 
while I still had the code in my own hands. Preferably at compile time. 
That's why I support the mandatory default - no matter which way you 
want the default, the compiler will always warn you right there, when 
you compile the code.

Hauke