www.digitalmars.com         C & C++   DMDScript  

D - switch/branch: solution?

reply "Vathix" <vathix dprogramming.com> writes:
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
Dec 10 2003
next sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
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
Dec 10 2003
prev sibling next sibling parent Felix <Felix_member pathlink.com> writes:
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
Dec 10 2003
prev sibling next sibling parent "Vathix" <vathix dprogramming.com> writes:
 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.
Dec 10 2003
prev sibling next sibling parent Robert (Japanese) <Robert_member pathlink.com> writes:
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)
Dec 10 2003
prev sibling next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
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
Dec 10 2003
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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
Dec 10 2003
parent "Charles Sanders" <sanders-consulting comcast.net> writes:
Agree whole-heartedly here, make it a compile time error will save everyone
tons of headaches!  Why do at run-time when you can do at compile time ?

C

"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:br7q79$1dub$1 digitaldaemon.com...

 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
Dec 10 2003
prev sibling next sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
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
Dec 10 2003
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Apr 24 2004
parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Walter wrote:


 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.




(...)
The question should never be "X, yes or no?" As long as you have limited 
time and resources, you always have to look at the cost and the benefit 
of X. Questions should be "Is X worth the time" or "Will X or Y have a 
greater return on investment?"
(...)
-- Joel Spolsky



 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.



-- 
Julio César Carrascal Urquijo
Apr 26 2004
parent "Walter" <newshound digitalmars.com> writes:
"Julio César Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
news:c6jrct$1aev$1 digitaldaemon.com...

 (...)
 The question should never be "X, yes or no?" As long as you have limited
 time and resources, you always have to look at the cost and the benefit
 of X. Questions should be "Is X worth the time" or "Will X or Y have a
 greater return on investment?"
 (...)
 -- Joel Spolsky


Of course. Each proposal gets a cost benefit evaluation.
Apr 27 2004
prev sibling next sibling parent Juan C. <Juan_member pathlink.com> writes:
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
Dec 10 2003
prev sibling next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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)
}
Dec 10 2003
parent J Anderson <REMOVEanderson badmama.com.au> writes:
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
Dec 14 2003
prev sibling next sibling parent reply Lewis <dethbomb hotmail.com> writes:
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
 
 
 
 


i agree that one should leave the switch statement as is, to have it act 
unexpectedly to people who have used it for years isnt optimal IMO. I am 
strongly on the side of introducing a new construct like this one. (not 
that my opinion matters here lol)
Dec 10 2003
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Lewis wrote:

 i agree that one should leave the switch statement as is, to have it act 
 unexpectedly to people who have used it for years isnt optimal IMO. I am 
 strongly on the side of introducing a new construct like this one. (not 
 that my opinion matters here lol)


On the other hand, if someone is going to break switch/case, this is one 
of the best possible times. (no established language would dare doing 
such a thing)

  -- andy
Dec 10 2003
parent Hauke Duden <H.NS.Duden gmx.net> writes:
Andy Friesen wrote:

 On the other hand, if someone is going to break switch/case, this is one 
 of the best possible times. (no established language would dare doing 
 such a thing)


Yeah, but I think if you're going to break switch you should at least 
name it differently.

But I think I've said enough on this issue... ;)

Hauke
Dec 11 2003
prev sibling next sibling parent Felix <Felix_member pathlink.com> writes:
Yeah, and the time will decide... Maybe D version 2 will drop the switch
completely...


In article <br91di$6po$2 digitaldaemon.com>, Lewis says...

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
 
 
 
 


i agree that one should leave the switch statement as is, to have it act 
unexpectedly to people who have used it for years isnt optimal IMO. I am 
strongly on the side of introducing a new construct like this one. (not 
that my opinion matters here lol)
Dec 10 2003
prev sibling parent reply "Matthew Wilson" <matthew.hat stlsoft.dot.org> writes:
"Lewis" <dethbomb hotmail.com> wrote in message
news:br91di$6po$2 digitaldaemon.com...

 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


 i agree that one should leave the switch statement as is, to have it act
 unexpectedly to people who have used it for years isnt optimal IMO. I am
 strongly on the side of introducing a new construct like this one. (not
 that my opinion matters here lol)


Everyone's opinion matters. :)



 Dec 11 2003



  parent reply "Sean L. Palmer" <palmer.sean verizon.net>  writes:


"Matthew Wilson" <matthew.hat stlsoft.dot.org> wrote in message
news:br9bhn$p66$1 digitaldaemon.com...

 i agree that one should leave the switch statement as is, to have it act
 unexpectedly to people who have used it for years isnt optimal IMO. I am
 strongly on the side of introducing a new construct like this one. (not
 that my opinion matters here lol)


 Everyone's opinion matters. :)


You'd like to believe that, wouldn't you?  ;)

Apparently our opinions only matter if we are able to express them
compellingly enough that Walter changes his mind.  Which is not easy.

Sean



 Dec 11 2003



 next sibling parent reply "Matthew Wilson" <matthew.hat stlsoft.dot.org>  writes:


"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:brai2b$2jj9$1 digitaldaemon.com...

 "Matthew Wilson" <matthew.hat stlsoft.dot.org> wrote in message
 news:br9bhn$p66$1 digitaldaemon.com...

 i agree that one should leave the switch statement as is, to have it






act

 unexpectedly to people who have used it for years isnt optimal IMO. I






am

 strongly on the side of introducing a new construct like this one.






(not

 that my opinion matters here lol)


 Everyone's opinion matters. :)


 You'd like to believe that, wouldn't you?  ;)

 Apparently our opinions only matter if we are able to express them
 compellingly enough that Walter changes his mind.  Which is not easy.


Well I was being a bit existentialist, and a bit nice (I thought I'd try it
out, so see how it feels).

However, despite Walter's recent post saying something about sometimes
having to pick something and stick with it or nothing will get done, I don't
believe that he is 100% intractable on any issue. 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. If
this weren't the case why would we bother; I've already said that putting in
the default is as automatic to me as putting in braces for every conditional
block, so it's not going to hurt me, just people new to the language with
different habits to mine (and Walter's!).

But you're right. It's not easy to get him to change his mind.



 Dec 11 2003



  parent reply J Anderson <REMOVEanderson badmama.com.au>  writes:


Matthew Wilson wrote:


"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:brai2b$2jj9$1 digitaldaemon.com...
  


"Matthew Wilson" <matthew.hat stlsoft.dot.org> wrote in message
news:br9bhn$p66$1 digitaldaemon.com...
    


i agree that one should leave the switch statement as is, to have it
        






act
  


unexpectedly to people who have used it for years isnt optimal IMO. I
        






am
  


strongly on the side of introducing a new construct like this one.
        






(not
  


that my opinion matters here lol)
        


Everyone's opinion matters. :)
      


You'd like to believe that, wouldn't you?  ;)

Apparently our opinions only matter if we are able to express them
compellingly enough that Walter changes his mind.  Which is not easy.
    



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. 
  



pressure on MS to do this.
http://msdn.microsoft.com/vcsharp/team/language/ask/switch/default.aspx



 Dec 11 2003



  parent reply Felix <Felix_member pathlink.com>  writes:


Yeah, I like the "goto" style, it is the most useful in a switch. No joke



In article <brask8$21c$1 digitaldaemon.com>, J Anderson says...

Matthew Wilson wrote:


"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:brai2b$2jj9$1 digitaldaemon.com...
  


"Matthew Wilson" <matthew.hat stlsoft.dot.org> wrote in message
news:br9bhn$p66$1 digitaldaemon.com...
    


i agree that one should leave the switch statement as is, to have it
        






act
  


unexpectedly to people who have used it for years isnt optimal IMO. I
        






am
  


strongly on the side of introducing a new construct like this one.
        






(not
  


that my opinion matters here lol)
        


Everyone's opinion matters. :)
      


You'd like to believe that, wouldn't you?  ;)

Apparently our opinions only matter if we are able to express them
compellingly enough that Walter changes his mind.  Which is not easy.
    



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. 
  



pressure on MS to do this.
http://msdn.microsoft.com/vcsharp/team/language/ask/switch/default.aspx





 Dec 11 2003



  parent reply J Anderson <REMOVEanderson badmama.com.au>  writes:


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.


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. 
 

      



pressure on MS to do this.
http://msdn.microsoft.com/vcsharp/team/language/ask/switch/default.aspx

    







 Dec 11 2003



  parent reply Felix <Felix_member pathlink.com>  writes:


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.


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. 
 

      



pressure on MS to do this.
http://msdn.microsoft.com/vcsharp/team/language/ask/switch/default.aspx

    









 Dec 12 2003



  parent reply J Anderson <REMOVEanderson badmama.com.au>  writes:


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...

  



way is better then we have now for D, but we could do much better.

-Anderson



 Dec 12 2003



  parent  Ian Johnston <Ian_member pathlink.com>  writes:


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

[...]



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.



 Dec 12 2003



prev sibling  parent reply Georg Wrede <Georg_member pathlink.com>  writes:


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


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.



 Dec 13 2003



  parent  Ilya Minkov <minkov cs.tum.edu>  writes:


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



 Dec 14 2003



prev sibling  parent reply "Mark Brudnak" <malibrud provide.net>  writes:


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





 Dec 12 2003



  parent  J Anderson <REMOVEanderson badmama.com.au>  writes:


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
  


    



  





 Dec 12 2003