in operator generalization

[Les Baker]

> I think it might be better to keep this in library code, i.e. it could 
> be  achieved with a utility functions or template. i.e. a template that 
> does a  binary search of a (presumed sorted) object which can be indexed 
> with [],  etc. It could then be used on dynamic/static arrays and other 
> container  style objects. This sort of thing is what I'd expect to see 
> in the  proposed DTL library.

You make a very good point, because all "in" is, is a shortcut for a 
method call.  But why even have "in" in the first place, if it's just 
has one limited usage (looking up a key in an AA)?  Looking at Python, 
IIRC, they allow "in" on lists and tuples, and allow overloading on it 
(__contains__).  Why not D?  (Actually D's seems better -- you get the 
object as a result -- Python's "in" just gives a boolean stating whether 
the list/dictionary contains the object.  Again, that's just from 
memory, could be wrong)

I'm digressing though, although I do desire an increase in orthogonality 
(Additionally, I like the "out-loud" readability of "in"; it does 
exactly what it says, and means the exact same thing as the discrete 
math "in" membership test operator).... I do agree that as much as 
possible should be kept in the library.  But I'm thinking only 
linear/binary search (based upon the "sortedness" of the array) would 
have to be added internally.  Custom containers (like you mentioned that 
would be coming in DTL) would implement their own "opIn", so that would 
definately be kept totally in the standard library, and of course 
equality testing would be delegated as well.  I think this needs more 
thought, as there is a fine line between having too much built-in and 
not enough.  My main point is this though: why have an operator that can 
only be used on _one_ type of container?

Les Baker