> Well, yes, but you also have to prepare your mind for the change. This is a huge step.
 ;)

 (nah, just kidding, you're right, I didn't realize it :-P)

Ok, enough kidding around, lets get back to you helping me with 'code generalization' :P

Saaa wrote:
>  (nah, just kidding, you're right, I didn't realize it :-P)
> 
> Ok, enough kidding around, lets get back to you helping me with 'code generalization' :P

Write a lexer and a parser.

> Write a lexer and a parser.

how do you mean?

Hello Ary,

> Saaa wrote:
> 
>>> You missed the alternative syntax to get the same behaviour. But
>>> it's a very subtle difference.
>>> 
>> Do you mean the multiple cases?
>> http://www.digitalmars.com/d/1.0/statement.html#SwitchStatement
> Yes, but make the "multiple cases" the *only* way to make case
> statements fallthrough. That would be the change.
> 

that /does not/ support the use case I have used:


switch(n)
{
case 1:
   some_func();

case 2:
   some_other_func();
}

On Tue, 9 Jun 2009 16:28:58 +0000 (UTC), BCS wrote:

> Hello grauzone,
> 
>>> http://groups.google.com/group/net.lang.c/msg/66008138e07aa94c
>>> 
>> Many people (even Brian Kernighan?) have said that the worst feature of C is that switches don't break automatically before each case label.
>> 
>> Oh god, that's from 1984, and even today we're struggling with this bullshit in the most modern dialect of C, D.
>> 
> 
> I'm sorry, you don't have my sympathy on this one. There are to many place I've used fall throught to chuck it out.

It is not an either-or situation.

We achieved both models in the up-coming version of Euphoria, at the minor cost of a new keyword.

By default, it does not do fallthru. Each case is its own master and the physical placement inside the switch is not relevant.

   switch EXPR do
      case VAL1 then
          STATEMENTS...
      case VAL2 then
          STATEMENTS...
      case VAL3 then
          STATEMENTS...
   end switch

But, if for some good reason you need to do fallthru ...

   switch EXPR with fallthru do
      case VAL1 then
          STATEMENTS...
      case VAL2 then
          STATEMENTS...
      case VAL3 then
          STATEMENTS...
   end switch

It that situation, the absence of a 'break' means that program flow falls through to the next case. You can still insert 'break' at any point to skip to the end of the switch statement, even in the default format. However, additionally in the default format you can use 'fallthru' to let flow drop to the next case....

   switch EXPR do
      case VAL1 then
          STATEMENTS...

      case VAL2 then
          STATEMENTS...
          fallthru  -->>> This makes flow fall through.

      case VAL3 then
          STATEMENTS...
   end switch


So, if one considers improving D's switch, it is possible to have both models if one is not frightened of new keywords.

For example ...

  select (EXPR) {
     case VAL1:
            STATEMENTS...
     case VAL2:
            STATEMENTS...
     case VAL3:
            STATEMENTS...
  }

would only execute ONE of the selected cases.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Hello Derek,

> On Tue, 9 Jun 2009 16:28:58 +0000 (UTC), BCS wrote:
> 
>> I'm sorry, you don't have my sympathy on this one. There are to many
>> place I've used fall throught to chuck it out.
>>
[...] 
> However, additionally in the default format you can use
> 'fallthru' to let flow drop to the next case....
> 
> switch EXPR do
> case VAL1 then
> STATEMENTS...
> case VAL2 then
> STATEMENTS...
> fallthru  -->>> This makes flow fall through.
> case VAL3 then
> STATEMENTS...
> end switch
> So, if one considers improving D's switch, it is possible to have both
> models if one is not frightened of new keywords.
> 
> For example ...
> 
> select (EXPR) {
> case VAL1:
> STATEMENTS...
> case VAL2:
> STATEMENTS...
> case VAL3:
> STATEMENTS...
> }
> would only execute ONE of the selected cases.
> 

C# sort of takes this approach (by using goto case EXP;) but doesn't have any generic "goto next" ability and I would find that very painful in some template code.

On Tue, 09 Jun 2009 19:35:51 +0200, Saaa wrote:

>>> What kind of fall-throughs were these?
>>>
>>> A:
>>>
>>> case value1:
>>> case value2:
>>> case valueN:
>>>     code1();
>>>     break;
>>>
>>> B:
>>>
>>> case value1:
>>>     code1();
>>> case value2:
>>>     code2();
>>>     break;
>>
>> The solution is to forbid fallthrough, and change the switch syntax:
>>
>> switch(value) {
>>   case 1:
>>   case 2:
>> // something
>> break;
>> }
>>
>> gives: Error, missing break at the end of case1.
>>
>> But:
>>
>> switch(value) {
>>   case 1, 2:
>> // something
>> break;
>> }
>>
>> works as expected.
>>
>> What's wrong with that?
> 
> Doesn't support B :)

case value1:
  code1();
  goto case value2; // already valid D code
  // or
  goto case; // already valid D code
case value2:
  code2();
  break;

Should be uncommon enough that the extra clarification is warranted IMO.

I believe I've fallen victim to accidental fall-throughs more than I've found uses for them...

vote++

-Steve

> template duffs_device(alias id1, alias id2, alias s)
> {
>     void duff_loop()
>     {
> 	if (id1 < id2)
> 	{
> 	    typeof(id1) n = (id2 - id1 + 7) / 8;
> 	    switch ((id2 - id1) % 8)
> 	    {
> 		case 0:        do {  s();
> 		case 7:              s();
> 		case 6:              s();
> 		case 5:              s();
> 		case 4:              s();
> 		case 3:              s();
> 		case 2:              s();
> 		case 1:              s();
> 				  } while (--n > 0);
> 	    }
> 	}
>     }
> }
> 
> void foo() { writefln("foo"); }
> 
> void test()
> {
>     int i = 1;
>     int j = 11;
> 
>     mixin duffs_device!(i, j, delegate { foo(); } );
>     duff_loop();	// executes foo() 10 times
> }

The Duff's device is said to be an optimization, but I get blunt device only 0.7% slower.

template blunt_device(alias id1, alias id2, alias s)
{
	void blunt_loop()
	{
		if (id1 < id2)
		{
			typeof(id1) i = id2 - id1;
			while(i-->0)s();
		}
	}
}

Kagamin:
> The Duff's device is said to be an optimization, but I get blunt device only 0.7% slower.

Compilers already know about the Duff's device, and sometimes they use it automatically.

Bye,
bearophile