www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Issue 1323

reply bearophile <bearophileHUGS lycos.com> writes:
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
Jan 08 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
 Lines like this is present thousands of time in my Python code:


Sorry, I meant:
Lines like this are present thousands of times in my Python code:

Bye,
bearophile
Jan 08 2011
prev sibling next sibling parent reply BlazingWhitester <max.klyga gmail.com> writes:
On 2011-01-09 01:20:17 +0200, bearophile said:


 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


This feature was discussed before.
If 'in' operator was overladable, users would expect it to have some 
known complexity.

Having sintactic sugar for some operation means that it is supposed to 
be used widely, and using O(n) operations all over the place is not a 
good idea.

Also, IMO, it has no real advantage, why not use std.algorithm.find instead ?
Jan 08 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
BlazingWhitester:


 If 'in' operator was overladable, users would expect it to have some 
 known complexity.


Like O(n) for a linear search in an array.



 Having sintactic sugar for some operation means that it is supposed to 
 be used widely, and using O(n) operations all over the place is not a 
 good idea.


I have to search chars in strings, substrings in strings and items in arrays
about equally often if the syntax is built-in or it comes from one or more
library functions.

Well, not having a built-in array search, in D code I sometimes replace:
x in [1, 5, 7]
with
(x == 1 || x == 5 || x == 7)
that's just worse, longer, more bug-prone, less easy to read, and even a *dumb*
compiler as Shedskin is able to turn the first into the second when the array
is short.



 Also, IMO, it has no real advantage, why not use std.algorithm.find instead ?


The syntax is worse, I don't like to call a function for something so common
and basic. It's like calling a library function to join two strings (and
find("hello", "llox") doesn't return a boolean).

Bye,
bearophile
Jan 08 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 08 January 2011 16:19:21 bearophile wrote:

 BlazingWhitester:

 If 'in' operator was overladable, users would expect it to have some
 known complexity.


 
 Like O(n) for a linear search in an array.


opIndex is supposed to be restricted to n log(n), I belive (the complexity 
necessary to access an element in a balanced, binary tree). It can have lower 
complexity - like O(1) - but it's not supposed to have higher complexity. opIn 
is effectively the operator for checking whether you can index the given 
container with the given key/index. It's basically doing [key] and telling you 
whether it's there. So, it doesn't make sense that it would have lower
efficiency.

This has been discussed before, and while some people would like to be able to 
use opIn at higher complexities, that's not the way that it's intended to be 
used, so we're not about to make it work that way for built-in arrays.

- Jonathan M Davis
Jan 08 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 09.01.2011 03:03, schrieb Jonathan M Davis:

 On Saturday 08 January 2011 16:19:21 bearophile wrote:

 BlazingWhitester:

 If 'in' operator was overladable, users would expect it to have some
 known complexity.


 Like O(n) for a linear search in an array.


 opIndex is supposed to be restricted to n log(n), I belive (the complexity
 necessary to access an element in a balanced, binary tree). It can have lower
 complexity - like O(1) - but it's not supposed to have higher complexity. opIn
 is effectively the operator for checking whether you can index the given
 container with the given key/index. It's basically doing [key] and telling you
 whether it's there. So, it doesn't make sense that it would have lower
efficiency.

 This has been discussed before, and while some people would like to be able to
 use opIn at higher complexities, that's not the way that it's intended to be
 used, so we're not about to make it work that way for built-in arrays.

 - Jonathan M Davis


"restricted to n log(n)"? I think you meant just "log(n)"

As far as I remember the last discussion, it was considered to allow it for 
arrays of a constant size or with known (at compiletime) contents or something 
like that.
But then again, that would feel kind of inconsistent (syntax is allowed for 
fixed size arrays but not for dynamic arrays).

Cheers,
- Daniel
Jan 08 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 08 January 2011 18:10:01 Daniel Gibson wrote:

 Am 09.01.2011 03:03, schrieb Jonathan M Davis:

 On Saturday 08 January 2011 16:19:21 bearophile wrote:

 BlazingWhitester:

 If 'in' operator was overladable, users would expect it to have some
 known complexity.


 
 Like O(n) for a linear search in an array.


 
 opIndex is supposed to be restricted to n log(n), I belive (the
 complexity necessary to access an element in a balanced, binary tree).
 It can have lower complexity - like O(1) - but it's not supposed to have
 higher complexity. opIn is effectively the operator for checking whether
 you can index the given container with the given key/index. It's
 basically doing [key] and telling you whether it's there. So, it doesn't
 make sense that it would have lower efficiency.
 
 This has been discussed before, and while some people would like to be
 able to use opIn at higher complexities, that's not the way that it's
 intended to be used, so we're not about to make it work that way for
 built-in arrays.
 
 - Jonathan M Davis


 
 "restricted to n log(n)"? I think you meant just "log(n)"


Probably. Shamefully, if I'm not careful, I tend to mix those up if I don't
look 
them up. Regardless, it's whatever the complexity is to access a node on a 
balanced, binary tree.


 As far as I remember the last discussion, it was considered to allow it for
 arrays of a constant size or with known (at compiletime) contents or
 something like that.
 But then again, that would feel kind of inconsistent (syntax is allowed for
 fixed size arrays but not for dynamic arrays).


Something like that. I'd have to look at the discussion again to know exactly 
how it all went, but it was definitely the outcome that we're not going to have 
opIn on built-in arrays.

- Jonathan M Davis
Jan 08 2011
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/8/11 8:10 PM, Daniel Gibson wrote:

 Am 09.01.2011 03:03, schrieb Jonathan M Davis:

 On Saturday 08 January 2011 16:19:21 bearophile wrote:

 BlazingWhitester:

 If 'in' operator was overladable, users would expect it to have some
 known complexity.


 Like O(n) for a linear search in an array.


 opIndex is supposed to be restricted to n log(n), I belive (the
 complexity
 necessary to access an element in a balanced, binary tree). It can
 have lower
 complexity - like O(1) - but it's not supposed to have higher
 complexity. opIn
 is effectively the operator for checking whether you can index the given
 container with the given key/index. It's basically doing [key] and
 telling you
 whether it's there. So, it doesn't make sense that it would have lower
 efficiency.

 This has been discussed before, and while some people would like to be
 able to
 use opIn at higher complexities, that's not the way that it's intended
 to be
 used, so we're not about to make it work that way for built-in arrays.

 - Jonathan M Davis


 "restricted to n log(n)"? I think you meant just "log(n)"

 As far as I remember the last discussion, it was considered to allow it
 for arrays of a constant size or with known (at compiletime) contents or
 something like that.
 But then again, that would feel kind of inconsistent (syntax is allowed
 for fixed size arrays but not for dynamic arrays).


But the reason is rock solid. Consistency is important, but it's not 
everything.

Oh, I just realized - we could have sortedRange define opIn_r!


Andrei
Jan 08 2011
prev sibling parent reply Tomek =?ISO-8859-2?Q?Sowi=F1ski?= <just ask.me> writes:
Daniel Gibson napisa=B3:


 "restricted to n log(n)"? I think you meant just "log(n)"
=20
 As far as I remember the last discussion, it was considered to allow it f=


or=20

 arrays of a constant size or with known (at compiletime) contents or some=


thing=20

 like that.
 But then again, that would feel kind of inconsistent (syntax is allowed f=


or=20

 fixed size arrays but not for dynamic arrays).


If it's about compile-time, it can be done with template wizardry:

x in [1, 5, 7]  ->  x.in_!(1, 5, 7)

--=20
Tomek
Jan 09 2011
next sibling parent Mafi <mafi example.org> writes:
Am 09.01.2011 14:56, schrieb Tomek Sowiñski:

 Daniel Gibson napisa³:


 "restricted to n log(n)"? I think you meant just "log(n)"

 As far as I remember the last discussion, it was considered to allow it for
 arrays of a constant size or with known (at compiletime) contents or something
 like that.
 But then again, that would feel kind of inconsistent (syntax is allowed for
 fixed size arrays but not for dynamic arrays).


 If it's about compile-time, it can be done with template wizardry:

 x in [1, 5, 7]  ->   x.in_!(1, 5, 7)


Better yet, we could implement kind of Perl6 junctions. Just let 
anyOf(....) return a custom struct with overloaded operators which just 
do the operation on all operands and reduces the results with or (ie ||).

x == anyOf(3,4,5,42)
x == anyBetween(3, 12)

D is just great.
Jan 09 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Tomek Sowiñski:


 If it's about compile-time, it can be done with template wizardry:
 
 x in [1, 5, 7]  ->  x.in_!(1, 5, 7)


Or better, as a built in feature of arrays :-) But the asymmetry between
literals and normal arrays is silly.

Bye,
bearophile
Jan 09 2011
prev sibling parent reply Tomek =?ISO-8859-2?Q?Sowi=F1ski?= <just ask.me> writes:
bearophile napisa=B3:


 Also, IMO, it has no real advantage, why not use std.algorithm.find ins=




tead ? =20

=20
 The syntax is worse, I don't like to call a function for something so com=


mon and basic. It's like calling a library

 function to join two strings (and find("hello", "llox") doesn't return a =


boolean).

That can be pretty much solved with a wrapper:

bool has(alias pred =3D "a =3D=3D b", R, E)(R haystack, E needle) {
    return find(haystack, needle).empty;
}

-------

if (someString.has(c))
    ...

Can we add 'has' (or call it 'contains', I don't mind) to std.algorithm and=
 end the discussion?

--=20
Tomek
Jan 09 2011
parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 9/01/11 1:28 PM, Tomek Sowiński wrote:

 bearophile napisał:


 Also, IMO, it has no real advantage, why not use std.algorithm.find instead ?


 The syntax is worse, I don't like to call a function for something so common
and basic. It's like calling a library
 function to join two strings (and find("hello", "llox") doesn't return a
boolean).


 That can be pretty much solved with a wrapper:

 bool has(alias pred = "a == b", R, E)(R haystack, E needle) {
      return find(haystack, needle).empty;
 }

 -------

 if (someString.has(c))
      ...

 Can we add 'has' (or call it 'contains', I don't mind) to std.algorithm and
end the discussion?


What's wrong with std.algorithm.canFind?

http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html#canFind


bool canFind(alias pred = "a == b", Range, V)(Range range, V value);
Returns true if and only if value can be found in range. Performs 


Ο(r.length) evaluations of pred.
Jan 09 2011
next sibling parent reply Tomek =?ISO-8859-2?Q?Sowi=F1ski?= <just ask.me> writes:
Peter Alexander napisa=B3:


 What's wrong with std.algorithm.canFind?
=20
 http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html#canFind


That I didn't.. er.. find it :) Sorry for the noise.

--=20
Tomek
Jan 09 2011
parent Tomek =?ISO-8859-2?Q?Sowi=F1ski?= <just ask.me> writes:
Tomek Sowi=F1ski napisa=B3:


 What's wrong with std.algorithm.canFind?
=20
 http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html#canFind =20


=20
 That I didn't.. er.. find it :) Sorry for the noise.


One more thing: the overload for range in range search is missing. On the o=
ther hand, it's the only overload indexOf has, the other two are missing.

--=20
Tomek
Jan 09 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Peter Alexander:


 What's wrong with std.algorithm.canFind?


I will have to use it, then. Thank you for all the answers.

Bye,
bearophile
Jan 09 2011
prev sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
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.

This said, you could do something like the following:
----
import tango.core.Array;

struct Arr(T)
{
     T[] a;
     bool opIn_r(T val)
     {
         return a.find(val) != a.length;
     }
}
void main()
{
     auto myArr = Arr([1, 2, 3]);
     assert(1 in myArr);
}
----
I'm sure with some alias this magic from D2 you could make this function 
in an even nicer fashion.

-- 
Robert
http://octarineparrot.com/
Jan 08 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/8/11 8:07 PM, 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.


That's what I'm saying, in could work for literal arrays.

Andrei
Jan 08 2011
prev sibling parent reply Pelle <pelle.mansson gmail.com> writes:
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. :-)
Jan 09 2011
next sibling parent Peter Alexander <peter.alexander.au gmail.com> writes:
On 9/01/11 4:28 PM, Pelle wrote:

 On 01/09/2011 03:07 AM, Robert Clipsham wrote:

 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.


The inconsistency doesn't just affect readability, it's an issue of 
generic programming, too.

e.g.

bool containsAny(R1, R2)(R1 haystack, R2 needles)
{
   foreach (needle; needles)
     if (needle in haystack)
       return true;
   return false;
}

For hashtables, containsAny would look up keys, and for arrays it would 
look up values, which might not be obvious to the user of containsAny.

Also, I'm of the opinion that T[] should be replaceable with T[size_t] 
in most cases, and the differing semantics of 'in' would break that.

string[int] days1 = [0: "Sunday", 1: "Monday", ... ];
string[] days2 = ["Sunday", "Monday", ... ];

assert( days1[6] == "Saturday" ); // pass
assert( days2[6] == "Saturday" ); // pass

assert( "Saturday" in days1 ); // fail
assert( "Saturday" in days2 ); // pass

Personally I think that the semantics of 'in' for AAs should change to 
use values, but I doubt that's going to happen at this stage (if ever).
Jan 09 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 09 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
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
Jan 09 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Daniel Gibson:


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


In my dlibs1 I have used isIn(), but contains() is better than canFind().

Bye,
bearophile
Jan 09 2011
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 I'd be glad to change canFind to contains. Vote by replying to this. We  
 can put canFind on the slow deprecation chute.


Absolutely. canFind always sounded to me like "this container supports  
find".

-- 
Simen
Jan 09 2011
prev sibling next sibling parent reply Tomek =?ISO-8859-2?Q?Sowi=F1ski?= <just ask.me> writes:
Andrei Alexandrescu napisa=B3:


 I'd be glad to change canFind to contains. Vote by replying to this. We=20
 can put canFind on the slow deprecation chute.


Like!
Jan 09 2011
parent Peter Alexander <peter.alexander.au gmail.com> writes:
On 9/01/11 7:15 PM, Tomek Sowiński wrote:

 Andrei Alexandrescu napisał:


 I'd be glad to change canFind to contains. Vote by replying to this. We
 can put canFind on the slow deprecation chute.


 Like!


Up vote for me.
Jan 09 2011
prev sibling next sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 1/9/11 7:44 PM, Andrei Alexandrescu wrote:

 I'd be glad to change canFind to contains. Vote by replying to this. We
 can put canFind on the slow deprecation chute.


Changing the name to »contains« has my vote as well – »canFind« always 
sounds like a check whether the container can perform »find« to me…

David
Jan 09 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
While you're at it I would really like to have a remove method in
std.algorithm that can take an ElementType of a range as a predicate:

See my older topic:
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Removing_an_object_from_a_range_23212.html

An example would look like:
Object a, b, c;
Object[] arr = [a, b, c];
remove(arr, b)
// arr == [a, c];

Or should I just file this in bugzilla as a feature request?
Jan 09 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/9/11 1:30 PM, Andrej Mitrovic wrote:

 While you're at it I would really like to have a remove method in
 std.algorithm that can take an ElementType of a range as a predicate:

 See my older topic:
 http://www.digitalmars.com/d/archives/digitalmars/D/learn/Removing_an_object_from_a_range_23212.html

 An example would look like:
 Object a, b, c;
 Object[] arr = [a, b, c];
 remove(arr, b)
 // arr == [a, c];

 Or should I just file this in bugzilla as a feature request?


An algorithm can't change the topology of the range it works on.

Andrei
Jan 09 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
s/predicate/needle
Jan 09 2011
prev sibling next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 09/01/11 18:44, Andrei Alexandrescu wrote:

 I'd be glad to change canFind to contains. Vote by replying to this. We
 can put canFind on the slow deprecation chute.

 Andrei


++vote;

-- 
Robert
http://octarineparrot.com/
Jan 09 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/9/11 1:24 PM, Robert Clipsham wrote:

 On 09/01/11 18:44, Andrei Alexandrescu wrote:

 I'd be glad to change canFind to contains. Vote by replying to this. We
 can put canFind on the slow deprecation chute.

 Andrei


 ++vote;


I just remembered why I called it canFind: it clarifies we're talking of 
a linear operation (derived from find). "contains" suggests a fast set 
operation.

Andrei
Jan 09 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 09 January 2011 10:44:39 Andrei Alexandrescu wrote:

 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


I would remind you of http://d.puremagic.com/issues/show_bug.cgi?id=4405 where 
we considered replacing canFind() with any(). I think that contains() is
exactly 
what we should have for the typical case of dealing with finding a specific 
element in an array or container, but we probably should have any() for the 
general case where you're looking to see whether the given predicate is true
for 
_any_ element in the range. Adding all() to go along with it (as in it returns 
true if the given predicate is true for _all_ elements in the range) would be 
preferable.

However, I definitely think that having contains() makes a _lot_ of sense, 
because that is exactly the function name that most people are looking for when 
they want to know whether a particular element is in a range.

- Jonathan M Davis
Jan 09 2011