"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