"in" everywhere

[Andrei Alexandrescu]

On 10/7/10 12:28 CDT, Austin Hastings wrote:
> 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
>

Sorry, I disagree with this so completely, I wouldn't know where to start.

Andrei