"in" everywhere

[Steven Schveighoffer]

On Thu, 07 Oct 2010 13:28:51 -0400, Austin Hastings <ah08010-d at yahoo.com>  
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.

No, this is not just a difference in runtime, this is a difference in  
complexity.  The complexity of in on an associative array is O(1), the  
complexity of in on an array is O(n).  This is a huge difference from  
comparing multiplying floats and ints.

in's complexity should be O(lg(n)) or better.

I also disagree with Andrei that in could work on arrays in certain  
cases.  It has no business being called on an array, we already have find.

-Steve