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



 default case. This allows you to port C code easier. People who like



 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


  

(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


  

(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


 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


 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?



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



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



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



 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
        



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



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



that my opinion matters here lol)
        


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
        



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



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



that my opinion matters here lol)
        


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


  

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. 
 

      

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


  

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. 
 

      

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

[...]

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

 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?


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 */
    }
}

  

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
    

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?
    

    


Dec 12 2003