"in" everywhere

[Austin Hastings]

On 10/7/2010 10:52 AM, Andrei Alexandrescu wrote:
> On 10/7/10 6:54 CDT, atommixz wrote:
>> It would be nice if it were possible to use the "in" expression wherever
>> possible. Now it is only implemented for associative. arrays. (Weird).
>> Examples of how this could be used:
>> - Find string in string
>> - Search for a character in a string
>> - Search for an item in the array, array of characters, array of strings,
>> tuples, enum, structure
>> - what else?
>>
>> In Python done something like this.
>>
>> Here it would be useful to me
>> http://code.google.com/p/atommixz/source/browse/analyze-x86/analyze-x86.py
>>
>> http://code.google.com/p/atommixz/source/browse/analyze-x86/analyzex86.d
>
> 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

This is a non-argument. "In" is an operator. "*" is an operator. 
Everyone "knew" that multiplying longs was slower than multiplying ints. 
Everyone "knew" that multiplying floating point was slower than 
multiplying integers. But * was still defined for floating point types 
because it made sense.

If querying a collection for the presence of a key makes sense (and it 
does to me) then the operator should work across as many collections as 
possible, regardless of the running time.

(The presence of optimized variations is a bonus. Not a requirement.)

=Austin