January 03, 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

Next ›   Last »
1 2 3 4