Issue 11403 - functions in std.algo can't be used as pred
Summary: functions in std.algo can't be used as pred
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: phobos (show other issues)
Version: D2
Hardware: All All
: P2 normal
Assignee: No Owner
URL:
Keywords: rejects-valid
Depends on:
Blocks:
 
Reported: 2013-10-31 12:55 UTC by monarchdodra
Modified: 2014-01-06 10:30 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description monarchdodra 2013-10-31 12:55:31 UTC
There are a ton of functions in std.algorithm that can be customized with a predicate. At ton of them can also be used as predicates themselves. Here is a cool example:

assert(equal!equal([[1, 2], [3, 4]], iota(1, 5).chunks(2)));

The problem with this piece of code is that:
The inner "equal" only works because it itself doesn't have a predicate.
The outer "equal" works because it takes arguments.

However, neither of this works:
alias fun = equal!equal; //Nope
equal!(equal!equal))(3Dmatrix1, 3Dmatrix2); //Nope

It is *not* possible to declare an algorithm function with a predicate, unless you also specify the argument types. Long story short, they are not eagerly specialize-able.

"equal" (I think) is the most obvious offender, but so are any/all:
import std.ascii : isWhite;
assert( all!(any!isWhite)(["a a", "b b"])); //Nope
assert(!any!(all!isWhite)(["a a", "b b"])); //Nope

Any function that takes a pred (+an argument) and returns a bool is faulty. Here is a (probably incomplete) list:
-equal
-canFind
-any
-all
-cmp
Comment 2 github-bugzilla 2013-12-19 09:22:36 UTC
Commit pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/8ce977a8f081fe7832cfb02c235c31de703b29b4
Merge pull request #1676 from monarchdodra/algoPredicable

Issue 11403 - functions in std.algo can't be used as pred
Comment 4 monarchdodra 2014-01-06 10:30:34 UTC
I don't know if we can *really* consider this "resolved", but the most important functions are now pred-compatible.

For any other improvements, I think it might be worth looking into a more generic solution, maybe. I'll just close it, and we'll deal with any other issue on a case-by-case basis.