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
