www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: About switch case statements...

reply bearophile <bearophileHUGS lycos.com> writes:
Don:


 (providing that empty fall-through case statements remain valid; 
 disallowing them would be really annoying).



What's bad about forcing people to write:
case A, B, C:

Instead of:
case A:
case B:
case C:
?

Bye,
bearophile
Nov 16 2009
next sibling parent reply Justin Johansson <no spam.com> writes:
bearophile wrote:

 Don:
 

 (providing that empty fall-through case statements remain valid; 
 disallowing them would be really annoying).



 What's bad about forcing people to write:
 case A, B, C:
 
 Instead of:
 case A:
 case B:
 case C:
 ?
 
 Bye,
 bearophile



I don't know about "forcing people" to write such but perhaps it could 
be an "option for people" :-)

Actually I quite like the brevity you propose but would it be a 
challenge for the comma operator?

While ago, I got D multi-dimensional array syntax messed up and declared 
such an animal as
int[3,4,5] which effectively ended up declaring the beast as int[5].

Cheers
Justin
Nov 16 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 16 Nov 2009 15:48:16 +0300, Justin Johansson <no spam.com> wrote:


 bearophile wrote:

 Don:


 (providing that empty fall-through case statements remain valid;  
 disallowing them would be really annoying).



 case A, B, C:
  Instead of:
 case A:
 case B:
 case C:
 ?
  Bye,
 bearophile



 I don't know about "forcing people" to write such but perhaps it could  
 be an "option for people" :-)

 Actually I quite like the brevity you propose but would it be a  
 challenge for the comma operator?

 While ago, I got D multi-dimensional array syntax messed up and declared  
 such an animal as
 int[3,4,5] which effectively ended up declaring the beast as int[5].

 Cheers
 Justin



Wow, this definitely needs to be bug-reported!
Nov 16 2009
parent Justin Johansson <no spam.com> writes:
Denis Koroskin wrote:

 On Mon, 16 Nov 2009 15:48:16 +0300, Justin Johansson <no spam.com> wrote:
 

 bearophile wrote:

 Don:


 (providing that empty fall-through case statements remain valid; 
 disallowing them would be really annoying).



 case A, B, C:
  Instead of:
 case A:
 case B:
 case C:
 ?
  Bye,
 bearophile



 I don't know about "forcing people" to write such but perhaps it could 
 be an "option for people" :-)

 Actually I quite like the brevity you propose but would it be a 
 challenge for the comma operator?

 While ago, I got D multi-dimensional array syntax messed up and 
 declared such an animal as
 int[3,4,5] which effectively ended up declaring the beast as int[5].

 Cheers
 Justin



 Wow, this definitely needs to be bug-reported!



Wilco.

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.bugs&article_id=19904
Nov 16 2009
prev sibling parent grauzone <none example.net> writes:
Justin Johansson wrote:

 bearophile wrote:

 Don:


 (providing that empty fall-through case statements remain valid; 
 disallowing them would be really annoying).



 What's bad about forcing people to write:
 case A, B, C:

 Instead of:
 case A:
 case B:
 case C:
 ?

 Bye,
 bearophile



 I don't know about "forcing people" to write such but perhaps it could 
 be an "option for people" :-)
 
 Actually I quite like the brevity you propose but would it be a 
 challenge for the comma operator?
 
 While ago, I got D multi-dimensional array syntax messed up and declared 
 such an animal as
 int[3,4,5] which effectively ended up declaring the beast as int[5].



The comma operator is another piece of C cruft that needs to go.


 Cheers
 Justin
Nov 16 2009
prev sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:

 Don:
 

 (providing that empty fall-through case statements remain valid; 
 disallowing them would be really annoying).



 What's bad about forcing people to write:
 case A, B, C:
 
 Instead of:
 case A:
 case B:
 case C:
 ?
 
 Bye,
 bearophile



(1) "case A, B, C:" implies a relationship between A, B, and C, which 
might not exist. They may have nothing in common.
(2) it's an extremely common coding style in C, C++.
(3) it's more difficult to read.
Nov 16 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:


 (1) "case A, B, C:" implies a relationship between A, B, and C, which 
 might not exist. They may have nothing in common.



It's just a list of things, it's a syntax people adapts too. Here too there's
no relationship between x and foo:
int x, foo;



 (2) it's an extremely common coding style in C, C++.



If automatic fall-through becomes a syntax error, then allowing it for empty
case statements is a special case of a special case. This kind of complexity
kills languages. As they say in Python Zen:
Special cases aren't special enough to break the rules.
And this is D.



 (3) it's more difficult to read.



You can put items in one column anyway, so instead of:

case someverylongcase:
case anotherverylongcase:
case thelastverylongcase:

You can write:

case someverylongcase,
     anotherverylongcase,
     thelastverylongcase:

This is not so unreadable.

----------------------

Justin Johansson:


 Actually I quite like the brevity you propose but would
 it be a challenge for the comma operator?



That's already standard D syntax :-)
http://codepad.org/ByvTAs27

Bye,
bearophile
Nov 16 2009
parent Justin Johansson <no spam.com> writes:
bearophile wrote:

 Don:
 

 (1) "case A, B, C:" implies a relationship between A, B, and C, which 
 might not exist. They may have nothing in common.



 It's just a list of things, it's a syntax people adapts too. Here too there's
no relationship between x and foo:
 int x, foo;
 
 

 (2) it's an extremely common coding style in C, C++.



 If automatic fall-through becomes a syntax error, then allowing it for empty
case statements is a special case of a special case. This kind of complexity
kills languages. As they say in Python Zen:
 Special cases aren't special enough to break the rules.
 And this is D.
 
 

 (3) it's more difficult to read.



 You can put items in one column anyway, so instead of:
 
 case someverylongcase:
 case anotherverylongcase:
 case thelastverylongcase:
 
 You can write:
 
 case someverylongcase,
      anotherverylongcase,
      thelastverylongcase:
 
 This is not so unreadable.
 
 ----------------------
 
 Justin Johansson:
 

 Actually I quite like the brevity you propose but would
 it be a challenge for the comma operator?



 That's already standard D syntax :-)
 http://codepad.org/ByvTAs27
 
 Bye,
 bearophile




 That's already standard D syntax :-)





 What's bad about forcing people to write case A, B, C




Cheers.  Must go now to attend to some fall-through cases in my
switch statements.**  Justin.
Nov 16 2009
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 16 Nov 2009 14:34:37 +0100, Don wrote:


 bearophile wrote:

 Don:
 

 (providing that empty fall-through case statements remain valid; 
 disallowing them would be really annoying).



 What's bad about forcing people to write:
 case A, B, C:
 
 Instead of:
 case A:
 case B:
 case C:
 ?
 
 Bye,
 bearophile



 (1) "case A, B, C:" implies a relationship between A, B, and C, which 
 might not exist. They may have nothing in common.
 (2) it's an extremely common coding style in C, C++.
 (3) it's more difficult to read.



(1)  case A:
     case B:
     case C:
   implies that there is no relationship between A,B, and C, but which
might actually exist. They may have something common.
(2) it's an extremely common writing style in human languages, thus aids
readability.
(3)  case A:
     case B:
     case C:
   is ambiguous. It looks like the coder put in place markers for intended
code but forgot the code.


-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Nov 16 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Denis Koroskin wrote:

 BTW, if a macro was declared as
 
 #define BASIC_TYPES            \
          TOKwchar: case TOKdchar:        \
     case TOKbit: case TOKbool: case TOKchar:    \
     case TOKint8: case TOKuns8:        \
     case TOKint16: case TOKuns16:        \
     case TOKint32: case TOKuns32:        \
     case TOKint64: case TOKuns64:        \
     case TOKfloat32: case TOKfloat64: case TOKfloat80:        \
     case TOKimaginary32: case TOKimaginary64: case TOKimaginary80:    \
     case TOKcomplex32: case TOKcomplex64: case TOKcomplex80:    \
     case TOKvoid
 
 (note an absence of the first case) then it would cause compile-time 
 error instead of run-time bugs. Usage:
 
 switch (token) {
     case TOKidentifier:
     case TOKenum:
     case TOKstruct:
     case TOKimport:
     case BASIC_TYPES:
 }



I like that. Great suggestion!
Nov 16 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Derek Parnell wrote:

 On Mon, 16 Nov 2009 14:34:37 +0100, Don wrote:
 

 bearophile wrote:

 Don:


 (providing that empty fall-through case statements remain valid; 
 disallowing them would be really annoying).



 case A, B, C:

 Instead of:
 case A:
 case B:
 case C:
 ?

 Bye,
 bearophile



 might not exist. They may have nothing in common.
 (2) it's an extremely common coding style in C, C++.
 (3) it's more difficult to read.



 (1)  case A:
      case B:
      case C:
    implies that there is no relationship between A,B, and C, but which
 might actually exist. They may have something common.



Yes, of course! In which situation, you use case A, B, C:
I'm not arguing AGAINST that syntax, which already exists!

Your other two comments aren't worth responding to.
Nov 17 2009
parent Derek Parnell <derek psych.ward> writes:
On Tue, 17 Nov 2009 09:05:48 +0100, Don wrote:


 Your other two comments aren't worth responding to.



I apologize.  I also don't know what I said to offend you. I've taken steps
to make sure it doesn't happen again.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Nov 17 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 16 Nov 2009 23:36:38 +0300, Derek Parnell <derek psych.ward> wrote:


 On Mon, 16 Nov 2009 14:34:37 +0100, Don wrote:


 bearophile wrote:

 Don:


 (providing that empty fall-through case statements remain valid;
 disallowing them would be really annoying).



 What's bad about forcing people to write:
 case A, B, C:

 Instead of:
 case A:
 case B:
 case C:
 ?

 Bye,
 bearophile



 (1) "case A, B, C:" implies a relationship between A, B, and C, which
 might not exist. They may have nothing in common.
 (2) it's an extremely common coding style in C, C++.
 (3) it's more difficult to read.



 (1)  case A:
      case B:
      case C:
    implies that there is no relationship between A,B, and C, but which
 might actually exist. They may have something common.
 (2) it's an extremely common writing style in human languages, thus aids
 readability.
 (3)  case A:
      case B:
      case C:
    is ambiguous. It looks like the coder put in place markers for  
 intended
 code but forgot the code.



When porting some C++ code to D (okay, it was DMDFE), I had exact same  
issue. There is the following macro defined:

#define CASE_BASIC_TYPES			\
	case TOKwchar: case TOKdchar:		\
	case TOKbit: case TOKbool: case TOKchar:	\
	case TOKint8: case TOKuns8:		\
	case TOKint16: case TOKuns16:		\
	case TOKint32: case TOKuns32:		\
	case TOKint64: case TOKuns64:		\
	case TOKfloat32: case TOKfloat64: case TOKfloat80:		\
	case TOKimaginary32: case TOKimaginary64: case TOKimaginary80:	\
	case TOKcomplex32: case TOKcomplex64: case TOKcomplex80:	\
	case TOKvoid

and if was used (and got translated to D) as follows:

switch (token) {
     case TOKidentifier:
     case TOKenum:
     case TOKstruct:
     case TOKimport:
     CASE_BASIC_TYPES:
}

Did you noticed it already? It is a valid C code *but* has different  
semantics! In D, CASE_BASIC_TYPES is merely a label, and it does just  
nothing. Needless to say the code compiled successfully, but produced  
weird error messages at run-time.

BTW, if a macro was declared as

#define BASIC_TYPES			\
	     TOKwchar: case TOKdchar:		\
	case TOKbit: case TOKbool: case TOKchar:	\
	case TOKint8: case TOKuns8:		\
	case TOKint16: case TOKuns16:		\
	case TOKint32: case TOKuns32:		\
	case TOKint64: case TOKuns64:		\
	case TOKfloat32: case TOKfloat64: case TOKfloat80:		\
	case TOKimaginary32: case TOKimaginary64: case TOKimaginary80:	\
	case TOKcomplex32: case TOKcomplex64: case TOKcomplex80:	\
	case TOKvoid

(note an absence of the first case) then it would cause compile-time error  
instead of run-time bugs. Usage:

switch (token) {
     case TOKidentifier:
     case TOKenum:
     case TOKstruct:
     case TOKimport:
     case BASIC_TYPES:
}
Nov 16 2009