Issue 1323

[Daniel Gibson]

Am 09.01.2011 19:44, schrieb Andrei Alexandrescu:
> On 1/9/11 10:28 AM, Pelle wrote:
>> On 01/09/2011 03:07 AM, Robert Clipsham wrote:
>>> On 08/01/11 23:20, bearophile wrote:
>>>> Andrei has recently closed issue 1323, it's a small but very useful
>>>> feature, so I suggest some public discussion:
>>>> http://d.puremagic.com/issues/show_bug.cgi?id=1323
>>>>
>>>> Lines like this is present thousands of time in my Python code:
>>>> n in [1, 2, 3]
>>>> c in "hello"
>>>> "llo" in some_string
>>>>
>>>> Bye,
>>>> bearophile
>>>
>>> I'd be all for this, except it's inconsistent.
>>> ----
>>> auto arr = [ "foo" : 1, "bar" : 2 ];
>>> assert("foo" in arr);
>>> ----
>>> in for associative arrays works by key, if it works by value for normal
>>> arrays it's inconsistent, and if it works for keys people will wonder
>>> why it's not working as expected.
>>
>> No, people will not wonder about that. See also: python. Seriously
>> people, stop giving this as a reason.
>>
>> A much better argument is the in operator should run in O(log n) for
>> anything, meaning it won't work for a general unsorted array.
>>
>> I suggest going for (v in assumeSorted(arr)) or (arr.contains(v)), where
>> contains is the canFind function blessed with a new, superior name. :-)
>
> I'd be glad to change canFind to contains. Vote by replying to this. We
> can put canFind on the slow deprecation chute.
>
> Andrei

Yeah, "contains" sounds better than "canFind", so
++vote