www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 4405] New: all function - returns whether predicate is true for all elements in a range

reply d-bugmail puremagic.com writes:
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



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: -------
Jun 28 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4405


Andrei Alexandrescu <andrei metalanguage.com> changed:

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



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: -------
Jun 28 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4405




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: -------
Jun 28 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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



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: -------
Jun 28 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4405




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: -------
Jun 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4405


bearophile_hugs eml.cc changed:

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



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: -------
Feb 07 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4405




*** 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: -------
Feb 07 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4405




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: -------
Jan 20 2012
prev sibling parent d-bugmail puremagic.com writes:
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



This has been merged.

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