Improvement to switch-case statement
Yigal Chripun
yigal100 at gmail.com
Sat Jan 3 07:51:05 PST 2009
Stewart Gordon wrote:
>> Stewart Gordon wrote:
>>> Yigal Chripun wrote:
>>> <snip>
>>>> IMO, either the switch statement should remain the low level
>>>> (effiecient) construct as in C, or replaced by a general mechanism of
>>>> pattern matching. your solution is kinda between the two above options
>>>> and I don't see the point of it.
>>>
>>> What would a "general mechanism of pattern matching" involve, and how
>>> would it replace switch? Would it replace if as well?
>>>
>>>> I'd personally prefer pattern matching to be added to D and the switch
>>>> to be deprecated and eventually removed from the language.
>>>
>>> I'd personally prefer my proposal from years ago to be taken seriously:
>>> http://www.digitalmars.com/d/archives/22722.html
>>>
>>> ISTM silly to improve switch but at the same time keep it restricted to
>>> the same old arcane syntax.
>>>
>>> Stewart.
>>
>> I have several idea on this, nothing finished though:
>>
>> the only reason for switch in the first place is an optimization in
>> the compiler, besides that, there is no need for it at all and
>> everything can be done with a bunch of if statements.
>>
>> we basically need a way to group several if/case statements together
>> and make them refer the same variable.
>>
>> here's a first attempt:
>>
>> match (value) {
>> case(1) foo();
>> case(2..4) { foo(); case(3) foo3(); bar(); continue; }
>> case(5) {...}
>> case() {...} // this is the default case
>> }
>
> So you make the () required so that the {} can be optional. At least
> it's consistent with most other control flow statements this way.
>
> I'm not sure why you need to use up another keyword for this - switch
> would work fine. At least, I don't think it would lead to any parsing
> ambiguity, though it might take quite a bit of lookahead to determine
> which switch syntax is being used.
>
> Would continue jump straight into the next case block that is a sibling
> of the current one, whatever it may be, or what? And where there are
> uncased statements at the same block level as cased statements, under
> what circumstances will they be executed?
>
> Moreover, will "default" still be legal in place of "case()"?
>
> Stewart.
like I said, this is just my first attempt...
to answer your questions:
1) new keyword is like you said - to prevent ambiguity, but if the
compiler can use "switch" without any parsing dificulties than I'm all
for utilizing "switch".
2) requiring () is more consistent with the rest of D - const(..),
cast(..), etc... also, this way as you noted, the {} are optional
3) continue should be consistent with loops, so it'll jump to next case
in list - like current switch fall-through, (similar to 'continue' to
next iteration in loop) and if you nest cases or want to skip a case
than you can add a label and continue to that label as well.
4) I'm not sure about 'default' isn't it a waste to make it a keyword
just for this? is it used anywhere else in the language?
5) i'm unsure about uncased statements - does it make sense to prohibit
those?
6)another thing is adding ability to decompose stuff like in FP, for
example:
match (arr) { // dynamic array
case([a, b]) { use a, b here } // match if array has two elements
...
}
More information about the Digitalmars-d
mailing list