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