"in" everywhere

[Andrei Alexandrescu]

On 10/7/10 10:39 CDT, Daniel Gibson wrote:
> Andrei Alexandrescu schrieb:
>> On 10/7/10 9:59 CDT, Daniel Gibson wrote:
>>> Andrei Alexandrescu schrieb:
>>>> 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
>>>
>>> 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.
>>
>
> So what about static arrays?

Same deal - same as literal arrays: they can be searched. The expected 
run time is known during compilation and independent of the input size.

Andrei