Felix wrote:

>Yeah, I like the "goto" style, it is the most useful in a switch. No joke
>
>
>  
>
I don't.  Even that article mentions that people ask why they have to put in the break or use fall through.

"As a result of the C# rules requiring explicit flow-control to occur at the end of a case block (most usually a break), many people question why the behavior simply wasnt changed such that fall-through didnt occur.  That is, dont make break required, simply change the semantics of switch to not have fall-through for cases.  The reason this wasnt done was so that developers who were very used to C++ wouldnt have a hard time understanding what a switch statement was doing."

Why do we have to hang on to bad habits.

>>>Given the clear
>>>unpopularity of the switch issue, and people's unwillingness to drop it, I
>>>can't believe he'd be so foolhardy as to simply thumb his nose at us. After
>>>all, we're not all hot under the collar on this issue because we think D is
>>>shit, or we want it to fail. Quite the contrary, we like D and we want it to
>>>succeed, and we don't want it to have such clear warts on it that will
>>>(rightly) bring strong criticism from anyone who does seek to do it down. 
>>> 
>>>
>>>      
>>>
>>Even C# changed the switch statement.  There must have been allot of pressure on MS to do this.
>>http://msdn.microsoft.com/vcsharp/team/language/ask/switch/default.aspx
>>
>>    
>>

I agrre, but:

-if falltrough is dropped, sometimes, in order to: avoid duplicating code & not
use dummy-like functions, you need to "falltrough".
-so, the only thing I said was that the goto allows that, on that example...
-the MS motivation (req. break etc.) seems to be for children...



In article <brbqkb$1cil$1@digitaldaemon.com>, J Anderson says...
>
>Felix wrote:
>
>>Yeah, I like the "goto" style, it is the most useful in a switch. No joke
>>
>>
>> 
>>
>I don't.  Even that article mentions that people ask why they have to put in the break or use fall through.
>
>"As a result of the C# rules requiring explicit flow-control to occur at the end of a case block (most usually a break), many people question why the behavior simply wasnt changed such that fall-through didnt occur. That is, dont make break required, simply change the semantics of switch to not have fall-through for cases.  The reason this wasnt done was so that developers who were very used to C++ wouldnt have a hard time understanding what a switch statement was doing."
>
>Why do we have to hang on to bad habits.
>
>>>>Given the clear
>>>>unpopularity of the switch issue, and people's unwillingness to drop it, I
>>>>can't believe he'd be so foolhardy as to simply thumb his nose at us. After
>>>>all, we're not all hot under the collar on this issue because we think D is
>>>>shit, or we want it to fail. Quite the contrary, we like D and we want it to
>>>>succeed, and we don't want it to have such clear warts on it that will
>>>>(rightly) bring strong criticism from anyone who does seek to do it down.
>>>> 
>>>>
>>>> 
>>>>
>>>Even C# changed the switch statement.  There must have been allot of pressure on MS to do this. http://msdn.microsoft.com/vcsharp/team/language/ask/switch/default.aspx
>>>
>>> 
>>>
>
>

Felix wrote:

>I agrre, but:
>
>-if falltrough is dropped, sometimes, in order to: avoid duplicating code & not
>use dummy-like functions, you need to "falltrough".
>-so, the only thing I said was that the goto allows that, on that example...
>-the MS motivation (req. break etc.) seems to be for children...
>
>  
>
My statement, probably came across too tough.  I feel that the C#-switch way is better then we have now for D, but we could do much better.

-Anderson

In article <brcdd0$284k$1@digitaldaemon.com>, J Anderson says...

[...]

>My statement, probably came across too tough.  I feel that the C#-switch way is better then we have now for D, but we could do much better.

I agree that we could probably do better, but my preferred solution would be to introduce a new keyword (like the "branch" suggested) and make it clearly different behaviour from the switch.

After all, I don't see anyone suggesting this:

if (x == 1)      { /* ... */ }
else if (x == 2) { /* ... */ }
// else the runtime throws an exception

which is intuitively the same as a switch with no default.

FWIW I think there should only be one 'switch-like' branching structure.  I propose the introduction of a new key word 'cases' to indicate multiple labels which fall through.  Each 'case' or 'cases' must be followed by a block statement or a sequence of statements followed by a 'break'.  The default case is required but as a label which may follow a 'case' or 'cases' keyword.  Consider the following examples:

switch(val)
{
    case 1:{...} // no break required, implied by block
    case 2:
        foo = bar ;
        foot = bart ;
        break ;    // break required
    cases 3, 5, 6, 9, 10, 99: { ... } // no break required.
    cases 4, 7, 8 :
        food = getJob(bard) ;
        break ;     // break required
    case default: { }
}

Also default could occur in one of the 'cases'.

switch(name)
{
    case "larry":
    {    giveRaise(name) ;
    }
    case "curley":
    {    promote(name) ;
    }
    cases "moe", default :  // presumably the default would handle "shemp",
etc.
    {    /* empty */
    }
}

"Vathix" <vathix@dprogramming.com> wrote in message news:br6ke3$2j1b$1@digitaldaemon.com...
> 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
>
>
>
>

Mark Brudnak wrote:

>FWIW I think there should only be one 'switch-like' branching structure.  I
>propose the introduction of a new key word 'cases' to indicate multiple
>labels which fall through.  Each 'case' or 'cases' must be followed by a
>block statement or a sequence of statements followed by a 'break'.  The
>default case is required but as a label which may follow a 'case' or 'cases'
>keyword.  Consider the following examples:
>
>switch(val)
>{
>    case 1:{...} // no break required, implied by block
>    case 2:
>        foo = bar ;
>        foot = bart ;
>        break ;    // break required
>    cases 3, 5, 6, 9, 10, 99: { ... } // no break required.
>    cases 4, 7, 8 :
>        food = getJob(bard) ;
>        break ;     // break required
>    case default: { }
>}
>
>Also default could occur in one of the 'cases'.
>
>switch(name)
>{
>    case "larry":
>    {    giveRaise(name) ;
>    }
>    case "curley":
>    {    promote(name) ;
>    }
>    cases "moe", default :  // presumably the default would handle "shemp",
>etc.
>    {    /* empty */
>    }
>}
>
>  
>
One problem with the block, is that it's valid syntax in C, and you use it when you want to keep variables local. Therefore->porting problems.  That's why I suggested that the : be removed for these cases to make porting easier.  But I like the "cases" word.

>"Vathix" <vathix@dprogramming.com> wrote in message
>news:br6ke3$2j1b$1@digitaldaemon.com...
>  
>
>>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
>  
>
>>
>>
>>    
>>
>
>
>  
>

In article <brai2b$2jj9$1@digitaldaemon.com>, Sean L. Palmer says...
>Apparently our opinions only matter if we are able to express them compellingly enough that Walter changes his mind.  Which is not easy.

That is correct. This is Walter's own language, and we should not forget it. We are here only as guests, and he's never _asked_ us to be here.

I came here tonight, (after a couple of days's break since I got frustrated at the switch issue) with the express purpose of writing a democratic letter stating that we should not push this issue too far.

The idea being that I've been in several arguments through the years with my subordinates. Some of the time I've _known_ that I'm right, but haven't been able to convince the others. Now, that is really frustrating. (I also lived at one time with this woman who won every single argument, no matter who really was right. Grr. And she knew it!)

So, Walter has an unbelievably long, and equally prosperous career as a compiler developer. If he is not able to convince us that his way of handling the switch statement is right, then it may either be because he is unable to find the right words, or it just might be that we are unable to grasp the point. Either way we should leave the issue, and give Walter some slack here.

Of course, writing compilers may be different than writing software in general, and very different from non-guru writing, especially for less-than-3-years-of-D-experience guys. But even in that case we should trust that Walter is able to view it from these points too.

Sigh, and then I read all the switch comments from the last few days. I got overwhelmed with "our" point of view.

Maybe we really should have two distinct multiple-choice statements? The old switch, as-is, and then a new one, probably called branch, as was suggested.

Quite a few things speak for it. The language is new enough for us to afford some forages to "new" territory. In time we could compare the usage of both, and maybe flag one of them as obsolete (in, like 2.0 or something?). Or then we just could leave them both in the language!

After all, we do have both while and do-while, both of which are just syntactic sugar on an if-goto construct.

Having both could be Publicly justified as making it easy for both C# and C(++) programmers to immigrate.

This would leave Walter in peace, settle the issue, calm our minds, maybe ease incomers' experience. Heh, and we could brag around for having the only language that supports two multipe-choice constructs.

Georg Wrede wrote:
> In article <brai2b$2jj9$1@digitaldaemon.com>, Sean L. Palmer says...
> 
>>Apparently our opinions only matter if we are able to express them
>>compellingly enough that Walter changes his mind.  Which is not easy.
> 
> That is correct. This is Walter's own language, and we should not
> forget it. We are here only as guests, and he's never _asked_ us to
> be here. 

Why, we are guests and he invited us. To drop in ideas, wishes, test, create publicity, show the problems, and let him decide and improve.

However, it's still his language, and the dictatorship of a trustworthy professional is still better than democracy of (potentially) fools. :) Even democracy of professionals give some of the most illegible papers: the C and the C++ standards. They might have some legal validity (reading legal documents was never intended to be fun, it was intended for the people who could drew some advantage for themselves ;> ), but they are clearly controversal at some points, so you cannot say that your understanding of a part of a document is right unless you read the rest, because other sections make implication which affect the rest... Which has its implications in *no* compiler being able to implement the standard. Ever.

I really admire the Walter's efforts, and his ability to put through his vision and his point of view from real *convincement*. Whatever opinion he ends at, it's probebly right, or at least he's sure it is. Who am i to tell him that something is *definately* wrong? It's just opinions.

> I came here tonight, (after a couple of days's break since I got frustrated at the switch issue) with the express purpose of writing
> a democratic letter stating that we should not push this issue too
> far. 

Very true. No, write a dictatoric letter. ;)
We have already put up all the points. So now calm down and see what we get.

> Maybe we really should have two distinct multiple-choice statements?
> The old switch, as-is, and then a new one, probably called branch,
> as was suggested. 

We shoule probably not. Having multiple equivalent constructs in the language has been pushed by C too far, and is the usual reason which makes reading code difficult. In C and C++ everyone develops his own style. Not so in Delphi, where you can read code from every other coder as if it was yours. Java avoids the problem to a major extent, and this should also be the point of D.

I had suggested that the new switch called "auto switch" or something like that, in the tradition of C qualifiers. But now i just say, leave the issue alone. It won't bite too often.

> Quite a few things speak for it. The language is new enough for us to
> afford some forages to "new" territory. In time we could compare the
> usage of both, and maybe flag one of them as obsolete (in, like 2.0
> or something?). Or then we just could leave them both in the language!

No, i believe Walter will never flag anything like that obsolete.

> This would leave Walter in peace, settle the issue, calm our minds,
> maybe ease incomers' experience. Heh, and we could brag around for
> having the only language that supports two multipe-choice constructs.

For people with no prior major exposure to C or Java, they would mix up the two and would never really remember: was this branch or switch to fall through? Do i use ":" here? Do i need a {} block? When reading code something wrong might be overlooked.

Speaking of 2.0, we will have a mechanism of syntactic extension. Everyone will be free to use whatever he pleases.

-eye

J Anderson 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.
>>
>> - 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 6: //C style case
> break; //C style break
> default : //D style (or C style)
> }
>  


Come to think of it, you could *almost* do the above idea in C using macros.

#define when break;case
#define others break;default

switch (val)
{
case 5: //First case can't be avoided
when 6:
when 100:
others:
}

-Anderson

"Antti Sykäri" <jsykari@gamma.hut.fi> wrote in message news:slrnbtehfk.5fp.jsykari@pulu.hut.fi...
> 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.

I agree, although I fall into that trap sometimes, too.

> 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 ;)

The "int x[]" C way may eventually get dropped. I'm thinking of dumping it from the D spec.

> 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);"

One of the hardest things in designing D is saying "no". I really do, deep down, want to implement everyone's features. But I know it would be a disaster for D to do this, both because it is an infinite time sink and 40 slightly different ways to do the same thing would just be a huge turnoff. So I'm left with making a decision about which way to go, often the decision is a little arbitrary, as making a less than perfect decision is better than indecision.

But that's not to say these decisions get made in a vacuum, quite the contrary. This newsgroup and the opinions and eloquence of the smart people here making their case is extremely valuable in trying to figure out the right direction to go. A very large part of D's design has come out of this newsgroup, and D would not be the big success it is today without it.