Thread overview
[Issue 4405] New: all function - returns whether predicate is true for all elements in a range
Jun 29, 2010
Jonathan M Davis
Jun 29, 2010
Jonathan M Davis
Jun 29, 2010
Jonathan M Davis
Jan 21, 2012
Jonathan M Davis
Jul 19, 2012
Brad Anderson
June 29, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4405

           Summary: all function - returns whether predicate is true for
                    all elements in a range
           Product: D
           Version: D2
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Phobos
        AssignedTo: nobody@puremagic.com
        ReportedBy: jmdavisProg@gmail.com


--- Comment #0 from Jonathan M Davis <jmdavisProg@gmail.com> 2010-06-28 20:19:42 PDT ---
Two very useful functions to have would what could be called any() and all(). They are, in a sense the || and && of a predicate against all elements a range. any() would take a predicate and a range and return whether any element in that range satisfied the predicate, shortcutting if it found one. all() would take a predicate and a range and return whether all elements in that range satisfied the predicate, shortcutting if it found one which didn't.

std.algorithm currently has canFind(), which is effectively any. One of its versions takes a predicate and a range and returns whether any of the elements satisfies the predicate. So, we basically have any() albeit by a different name and with the original intent of returning whether a particular element could be found in a range. Its definition is flexible enough that it does the job.

However, we have no function which would be all(). You can get similar behavior with various functions, but none of them take a predicate and return whether all elements of a range satisfy the predicate. The closest at present would be to use the negation of the predicate with canFind(). But not only is that like having to use || with ! to implement && (which while possible is rather annoying and often forces you to make your logic less clear), but it's likely to be less efficient to since you may have to wrap one predicate in another to get its negation. There may be other implementation details which affect efficiency as well, though I can't think of any off the top of my head at the moment.

In any case, it would be highly desirable if an all() function were added to
std.algorithm.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 29, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4405


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@metalanguage.com


--- Comment #1 from Andrei Alexandrescu <andrei@metalanguage.com> 2010-06-28 20:26:42 PDT ---
I prefer any() to canFind(). I agree that all() would be a good addition.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 29, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4405



--- Comment #2 from Jonathan M Davis <jmdavisProg@gmail.com> 2010-06-28 21:20:24 PDT ---
I'd love any() since it's nice and clear. It's just that as far as I can tell,
the version of canFind() which takes only a range (along with the predicate) is
exactly what any() would do. There may a difference, but I don't know what it
would be. But even if there isn't, it wouldn't hurt my feelings any to have
any() on top of canFind(). It just seemed likely that someone would complain
that it was cruft to have any() when canFind does exactly what any() would do.
I would prefer an explicit any() though, since it would be clearer in code what
you intended to do.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 29, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4405


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|nobody@puremagic.com        |andrei@metalanguage.com


--- Comment #3 from Andrei Alexandrescu <andrei@metalanguage.com> 2010-06-28 21:38:10 PDT ---
I think I'll define any() to replace canFind and will slowly deprecate canFind.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 29, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4405



--- Comment #4 from Jonathan M Davis <jmdavisProg@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: -------
February 07, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=4405


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #5 from bearophile_hugs@eml.cc 2011-02-07 15:08:28 PST ---
I have written a duplicated enhancement request: bug 5544

There I have asked an all() and any() that allow to write code as this:

import std.algorithm;
void main() {
    auto items = [1, 7, 22];
    bool r1 = all!q{a % 2}(items);
    assert(!r1);
    items = [1, 7, 21];
    bool r2 = all!q{a % 2}(items);
    assert(r2);
}

Instead of:

import std.algorithm;
void main() {
    auto items = [1, 7, 22];
    bool r1 = reduce!q{a && b}(true, map!q{a % 2}(items));
    assert(!r1);
    items = [1, 7, 21];
    bool r2 = reduce!q{a && b}(true, map!q{a % 2}(items));
    assert(r2);
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 07, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=4405



--- Comment #6 from bearophile_hugs@eml.cc 2011-02-07 15:08:53 PST ---
*** Issue 5544 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
January 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=4405



--- Comment #7 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-01-20 23:25:13 PST ---
https://github.com/D-Programming-Language/phobos/pull/344

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
July 19, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=4405


Brad Anderson <eco@gnuk.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |eco@gnuk.net
         Resolution|                            |FIXED


--- Comment #8 from Brad Anderson <eco@gnuk.net> 2012-07-19 00:06:58 PDT ---
This has been merged.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------