"in" everywhere
Jonathan M Davis
jmdavisProg at gmx.com
Thu Oct 7 10:26:15 PDT 2010
On Thursday, October 07, 2010 08:37:19 Andrei Alexandrescu wrote:
> >>
> >> I'm a bit leary of adopting this feature (it has been discussed). To
> >> me "in" implies a fast operation and substring searching isn't quite it.
> >>
> >> One thing that could be done is to allow "in" with literal arrays to
> >> their right:
> >>
> >> if (x in ["abcde", "asd"]) { ... }
> >>
> >> The size of the operand is constant, known, and visible.
> >>
> >>
> >> Andrei
> >
> > That feels inconsistent.. to be able to use it with "literal arrays to
> > their right" (and what about fixed size arrays?) but not with actual
> > arrays and dynamic arrays seems weird.
>
> It's not. It's all about constant size in the size of the input vs.
> arbitrary size. Makes perfect sense to me.
>
> Andrei
It feels inconsistent because it only works on a particular type (arrays) some
of the time. At least with associative arrays it _always_ works. You don't have
to worry about whether it's legal in a particular context. Being able to use in
on only a subset of arrays (like array literals) would not be consistent with
regards to type (even if it's consistent with regards to complexity) and could
lead to confusion.
Personally, I think that find() and indexof() do the the job just fine and I see
no need to expand in. Regardless, I certainly don't want to have in working on
arrays only some of the time. I completely agree with Daniel that doing so would
be inconsistent.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list