While restricting the value_type of the iterator to bool still solves most
of the cases where I needed this feature, I can also see several good use
cases for a value convertible to bool. E.g. a
std::vector<std::unique_ptr<T>> or a std::deque<std::optional<T>>.

@Jake: I understand your argument, but I believe if a (user defined)
conversion to bool causes a program to accidentially compile and produce
the wrong behavior, the blame is more on the person who maybe unmindfully
implemented this conversion. Furthermore, if omitting the predicate causes
undesired behavior, so would be accidentially omitting the predicate to
std::sort, when you intend to not sort by operator< but a custom comparison.

On Mon, 16 Dec 2019 at 19:07, Michael Hava <mfh_at_[hidden]> wrote:

> I like the idea and I think this could be done with trivial overloads as
> leaving the predicates out should lead to an unambiguous overloads for
> these functions.
>
>
>
> I don’t think there is any specific reason why none of these overloads
> exist – I’d venture a guess that they were never proposed. (You may want to
> find the original proposal for these functions for a rationale…)
>
> After all these functions are C++11 additions that “just” introduce more
> readable names for applications of std::find_if[_not].
>
>
>
>
>
> I’m a bit torn on the issue of enforcing that Iterator::value_type ought
> to be bool:
>
> I can understand the argument that it would be dangerous to allow any
> implicit conversion to bool as that could lead to code that has
> unexpected behavior.
>
> On the other hand I’ve seen countless uses of other types (e.g. char)
> instead of bool due to issues in the stdlib (vector<bool> being a prime
> offender).
>
> Furthermore something like all_of(begin(ptrVec), end(ptrVec)) would be a
> perfect example for a potential safe(!) use-case…
>
>
>
> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> *On Behalf
> Of *Bernhard Manfred Gruber via Std-Proposals
> *Sent:* Sunday, December 15, 2019 4:34 PM
> *To:* std-proposals_at_[hidden]
> *Cc:* Bernhard Manfred Gruber <bernhardmgruber_at_[hidden]>
> *Subject:* [std-proposals] std::any_of, std::all_of and std::none_of
> without predicate
>
>
>
> I sometimes intuitively write something along the lines:
>
> if (std::any_of(begin(v), end(v))) { }
>
>
> where v is a container of bools or something similar. And when I compile
> my code, reality hits. The std::any_of, std::all_of and std::none_of
> algorithms can only be called with a predicate as third argument.
>
>
>
> So I need to write
>
> if (std::any_of(begin(v), end(v), [](auto e) { return e; })) { }
>
>
>
> Or in C++20 I might be able to use std::identity. Still, the third
> argument feels unnecessary to me.
>
>
>
> This has been discussed before here:
> https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/all_of|sort:date/std-proposals/sKA_dDQiU_g/OTDMnQ7fBwAJ
>
> But the discussion quickly went off into various different proposals.
>
>
>
> Is there a compelling reason, why std::any_of, std::all_of and
> std::none_of do not have an overload without a predicate and just convert
> the elements of the passed range to bool?
>
> It feels like an oversight to me. Or maybe the use case is just too small?
>
>
>
> Anyway, thank you for the feedback!
>