Top 5

[Nick Sabalausky]

"Chris R. Miller" <lordsauronthegreat at gmail.com> wrote in message 
news:gcorva$2uf6$1 at digitalmars.com...
> Bruce Adams wrote:
>> On Thu, 09 Oct 2008 01:08:54 +0100, Chris R. Miller 
>> <lordsauronthegreat at gmail.com> wrote:
>>
>>> Mike wrote:
>>>> 4. Replace C-style switch with something modern and more D-like:
>>>>  switch (x)
>>>> {
>>>>     case (0) foo();
>>>>     case (1)
>>>>     {
>>>>         bar();
>>>>         baz();
>>>>     }
>>>>     else throw new Exception("nope");
>>>> }
>>>
>>> But that would break the techniques of a duff's device.  The existing 
>>> syntax of a switch statement is more accurate to how it behaves, 
>>> anyways.  It's like a more complex series of goto statements.
>>>
>>> http://en.wikipedia.org/wiki/Duff%27s_device
>>
>> Duff's device is a perversion. The compiler should be left to perform
>> those sorts of optimisations.
>
> I really don't trust the compiler to make those optimizations.  What if 
> someone makes a different compiler implementation and forgets to include 
> the new implicit optimizations?
>
> I also know people who work with real-time signal analysis algorithms, and 
> the flexibility of the switch statement really aids their bottom line of 
> performance.
>
>>> http://en.wikipedia.org/wiki/Switch_statement
>>>
>>> Your proposal really makes it redundant with chains of if-else 
>>> statements IMHO.
>>
>> The difference is a switch might be optimised into a look-up table.
>> A chain of if/then/else's requires a different kind of optimisation
>> thought it might end up in the same form.
>>
>> Though the main point is nothing to do with optimisation. Its about 
>> clarity
>> of intent. A switch selects possible values of a single item and can
>> be expected (in certain cases) to cover all cases. That is never true for
>> if-then-else.
>
> I was really thinking of if-if chains, sorry for the confusion, it was a 
> brain-language-keyboard deficiency.
>
> The switch statement as it currently is allows you a great degree of 
> flexibility if you know how to (ab)use it.  If it's so dumb, don't use it. 
> I really am not amenable to the concept of changing the switch statement 
> on such a fundamental level unless some clear advantage can be established 
> that doesn't compromise existing functionality.

I don't see any reason why adding a more modern switch would necessitate 
getting rid of the existing switch. I have no problem keeping the existing 
switch in the language, but I've always wanted a switch like this:

switch(any expression)
case(7) {}
case(2, 4, 10) {}
case(>= 25) {}
case(> 17, <= -10) {}
case(in 20..22) {}
case(!in MyIntArray) {}

Yea, I *can* code that with ifs (and currently do), but there are times when 
all of those ifs basically boil down to branching the execution based on the 
value of one single expression. That's a switch. But the conditions aren't 
always just a simple "==".

And if someone wants to make an old-style switch to manually implement a 
duff's, I say fine, let them.