--- Comment #4 from Jonathan M Davis <jmdavisp...@gmail.com> 2010-06-29
01:51:05 PDT ---
Actually, while I'd love to have any(), I do think that having canFind() would
make sense so long as it has versions of it which don't match any(). That is,
only the most general version of canFind() - the one that only takes a Range
(and of course the predicate) - matches up with any(). The other versions of
canFind() - as well as canFindSorted() - would definitely be nice to have in
addition to any(). If anything, I'd like to see a version of canFind() to match
each version of find() - the most glaring hole at the moment being the version
that takes a range of needles. There's lots of code where having canFind() be
the same as find() would make good sense and be more clear to the programmer.
I do think that it's a good idea to have any() separate from that, and perhaps
the version of canFind() which only takes the predicate and the range should be
removed, but I do think that it would be a loss to get rid of the other
versions of canFind(), and it would be rather odd to rename the other versions
of canFind() any().
So, I'd vote to add any() and all(), and then remove the version of canFind()
which only takes the predicate and the range.
That way, we have canFind() to match find() where it makes sense, and we have
the more general any() and all() where they make sense.
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------