View mode: basic / threaded / horizontal-split · Log in · Help
November 16, 2009
Re: About switch case statements...
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
November 16, 2009
Re: About switch case statements...
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
November 16, 2009
Re: About switch case statements...
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).
>>  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
>
>

Wow, this definitely needs to be bug-reported!
November 16, 2009
Re: About switch case statements...
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.
November 16, 2009
Re: About switch case statements...
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
November 16, 2009
Re: About switch case statements...
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
> 
>
November 16, 2009
Re: About switch case statements...
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
November 16, 2009
Re: About switch case statements...
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).
>>>  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
>>
>>
> 
> Wow, this definitely needs to be bug-reported!

Wilco.

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.bugs&article_id=19904
November 16, 2009
Re: About switch case statements...
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 :-)
Okay, thanks for reminding me.**

> What's bad about forcing people to write case A, B, C
So your use of the word "forcing" was quite intentional?

Cheers.  Must go now to attend to some fall-through cases in my
switch statements.**  Justin.
November 16, 2009
Re: About switch case statements...
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:
}
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home