I would also like to see regexp matching...this could be done, perhaps with a regexp keyword in the select() block:

char[] string = ...;
select(string)
{
    regexp("^asdf$")
        foo(string);
    retexp("^asdf")
        bar(string);
    regexp("asdf$")
        baz(string);
    default
        fred(string);
}

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C691185.6B118CF@deming-os.org...

> People have also talked about switches on strings or other types.
Frankly,
> I think that switches on arbitrary types is good, but switches on strings
> (i.e. arrays of chars and wchars) is almost "absolutely necessary".
> Trouble is, if you select() on an array, it's kind of ambiguous whether
> your're comparing the arrays (do the point to the same region and have the
> same length) or are you comparing the strings (would strcmp() return 0).
I

Just to remind, switch() in D already works with string. select()
should, too, in the same way.

Pavel Minayev wrote:

> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C691185.6B118CF@deming-os.org...
>
> > People have also talked about switches on strings or other types.
> Frankly,
> > I think that switches on arbitrary types is good, but switches on strings
> > (i.e. arrays of chars and wchars) is almost "absolutely necessary".
> > Trouble is, if you select() on an array, it's kind of ambiguous whether
> > your're comparing the arrays (do the point to the same region and have the
> > same length) or are you comparing the strings (would strcmp() return 0).
> I
>
> Just to remind, switch() in D already works with string. select()
> should, too, in the same way.

Sorry, I forgot. :(

As much as I wanted to be a cutting-edge D developer, I haven't had the time to even try.  I love the language, and plan to move my personal pet project to it as soon as a good cross platform UNIX/Windows compiler (or dfront) stabilizes. I'd do it right now, but I don't want to have to fork my UNIX and Windows code. :(

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Walter" <walter@digitalmars.com> wrote in message news:a4aril$ue9$1@digitaldaemon.com...
> The difficulty I have is I haven't had problems with switch in my own
code.

Well, I have.  But more importantly, I've had difficulty with switch in *other* people's code.  How much of other people's code have you looked at, or had to debug?

I've given this some thought, and IMHO, fallthrough behavior of switch is
more dangerous than useful.  Sure, I've personally used it to good effect
(in fact, just today), and without case enumerations and ranges it's
essential.  But if it were me, I would provide one switch() syntax (not
two), I'd make all cases exclusive (each case breaks at the end), and I'd
provide case ranges (1 ... 3) and enumerations (1, 2, 3).

If I really wanted to code a fallthrough, I'd do it the ugly way:

switch(a)
{
case 1, 2, 3:
    // do stuff for these cases
    goto do_other_case;
case 4 ... 10:
do_other_case:
    // It was ugly but I decided it was worth it.


> I do like the idea of having multiple case values, though. The case range
is
> a good idea, too. I don't want to change the fall through behavior,
though.
> Is it really such a problem?
>
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:a4ap6u$teg$1@digitaldaemon.com...
> > Yeah, once again back to the old topic... Walter, are you going
> > to provide some neater, more powerful, and less error-prone
> > alternative to this #&!% C switch()? It's one of the most frequent
> > sources of bugs, IMO, and the way it works is not intuitive
> > and absolutely anti-C(D), in general.
> >
> > My suggestion of syntax:
> >
> >     select (n)
> >     {
> >         case (0)
> >             foo();
> >         case (1, 3, 7)
> >         {
> >             int m = foo(n);
> >             bar(n);
> >         }
> >         case (2, 4 .. 6, 9)
> >             bar(n);
> >         default
> >             throw new Error;
> >     }
> >
> > This should deal with most switch() problems:
> >
> >     - no more break; only one case-block gets executed. Block statement
> >       is required if there are more then one statement in case (just
> >       like all other D constructs)
> >     - easy to check for several possible values and/or ranges
> >
> > What do you think of this?
> >
> >

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@comcast.net (personal)

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a4b19l$10s8$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a4arl2$ueu$1@digitaldaemon.com...
>
> > There is, in D, a break label construct enabling breaking out of any lexically enclosing loop.
>
> True. But labels and goto (or break & continue w/label) make code somewhat harder to read - because you have to find that label to follow the execution flow of the program. If you're lucky enough to mess with the code written by one of those holy guys that use strict formatting rules (like me =)), you have a chance to see it easily:
>
>     while(true)
>     {
>         switch()
>         {
>             ...
>             break Out;
>             ..
>         }
>     }
> Out:
>     ...
>
> However, it's so easy to write this code in such a way you'll spend several minutes trying to find that damn Out in a 10-screen function listing. Not the most productive way to spend your time, it is. =)

The label applies to the loop, your example should be:

    Out: while (true)
        {
            switch ()
                ....
                break Out;
            ....

Complex control flow spanning many screens is always going to be complex, I don't think there's much hope for that.

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C69122D.BE5F2EAE@deming-os.org...
> I would also like to see regexp matching...this could be done, perhaps
with
> a regexp keyword in the select() block:
>
> char[] string = ...;
> select(string)
> {
>     regexp("^asdf$")
>         foo(string);
>     retexp("^asdf")
>         bar(string);
>     regexp("asdf$")
>         baz(string);
>     default
>         fred(string);
> }

Oh, man, I do strings and he raises the bar wanting regexp <g>.

"Richard Krehbiel" <rich@kastle.com> wrote in message news:a4bk4v$1918$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a4aril$ue9$1@digitaldaemon.com...
> > The difficulty I have is I haven't had problems with switch in my own
> code.
> Well, I have.  But more importantly, I've had difficulty with switch in
> *other* people's code.  How much of other people's code have you looked
at,
> or had to debug?

Well, I do get emailed a lot of code I have to sort through looking for problems <g>.

"Walter" <walter@digitalmars.com> wrote in message news:a4bm6k$1a5o$4@digitaldaemon.com...

> Oh, man, I do strings and he raises the bar wanting regexp <g>.

Yeah, a bit too much =)

You can always use goto if you want to jump into another case.  Fallthru is not necessary once you can supply multiple arguments to each case.

Sean

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a4b10u$10li$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a4aril$ue9$1@digitaldaemon.com...
>
> > The difficulty I have is I haven't had problems with switch in my own
> code.
>
> It's the matter of experience, I believe. All amateur C programmers,
> especially those who came from other languages like BASIC or Pascal,
> with strict select-case statement, tend to forget to add the break
> at the end of case blocks. This is much like missing semicolons, but
> the latter is detected at compile-time, while one occasionaly missed
> break very often compiles silently and is then a source of hard-to-
> catch bugs. After some practice, though, you get used to break out
> of the cases - it took me about a month to polish my practical C skills
> (including switch-breaks) when I moved to C from Pascal.
>
> > I do like the idea of having multiple case values, though. The case
range
> is
> > a good idea, too. I don't want to change the fall through behavior,
> though.
> > Is it really such a problem?
>
> First of all, I suggest to leave the switch() construct untouched
> (note that I proposed another keyword, select()), for some compatibility
> with C, and for those [really rare] cases when you really need the
> fall-through behaviour, like one in this piece of code (from WinD):
>
>       case WM_LBUTTONDOWN:
>           if (handleClicks)
>               clicking = true;
>       case WM_RBUTTONDOWN:
>       case WM_MBUTTONDOWN:
>           mouseDown(new MouseEvent(this, wParam, lParam));
>           break;
>
> However, such code is typically hard to read, because you might assume
> there's a break statement where there isn't, or you might miss one
> that is really there... so the _recommended_ way would be to use select(),
> which is less prone for such errors.
>
>

I have at least 5 or 6 extremely hard to track down subtle bugs a year due to missing a break statement in a switch.  Doesn't matter who writes it, it is a major source of bugs.

Even experienced C coders sometimes forget it.

Sean

"Richard Krehbiel" <rich@kastle.com> wrote in message news:a4bk4v$1918$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a4aril$ue9$1@digitaldaemon.com...
> > The difficulty I have is I haven't had problems with switch in my own
> code.
>
> Well, I have.  But more importantly, I've had difficulty with switch in *other* people's code.  How much of other people's code have you looked
at,
> or had to debug?
>
> I've given this some thought, and IMHO, fallthrough behavior of switch is
> more dangerous than useful.  Sure, I've personally used it to good effect
> (in fact, just today), and without case enumerations and ranges it's
> essential.  But if it were me, I would provide one switch() syntax (not
> two), I'd make all cases exclusive (each case breaks at the end), and I'd
> provide case ranges (1 ... 3) and enumerations (1, 2, 3).
>
...
> > I do like the idea of having multiple case values, though. The case
range
> is
> > a good idea, too. I don't want to change the fall through behavior,
> though.
> > Is it really such a problem?

YES.