Jump to page: 1 2
Thread overview
Re: About switch case statements...
Nov 16, 2009
bearophile
Nov 16, 2009
Justin Johansson
Nov 16, 2009
Denis Koroskin
Nov 16, 2009
Justin Johansson
Nov 16, 2009
grauzone
Nov 16, 2009
Don
Nov 16, 2009
bearophile
Nov 16, 2009
Justin Johansson
Nov 16, 2009
Derek Parnell
Nov 16, 2009
Denis Koroskin
Nov 16, 2009
Walter Bright
Nov 17, 2009
Don
Nov 17, 2009
Derek Parnell
November 16, 2009
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
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
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
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
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
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
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
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
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
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