http://d.puremagic.com/issues/show_bug.cgi?id=4405
--- Comment #4 from Jonathan M Davis <[email protected]> 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: -------
