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
next sibling 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 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 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 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 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 

Jan 09 2011
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 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
prev sibling next 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 next 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 next 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 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
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 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 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 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
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 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
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
s/predicate/needle
Jan 09 2011
prev sibling 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 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=


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

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

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
prev sibling next sibling parent 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
prev sibling next sibling parent 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=

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

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

 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
prev sibling next sibling 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

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 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