Issue 1323

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sun Jan 9 10:44:39 PST 2011


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


More information about the Digitalmars-d mailing list