I'm slightly uneasy about this and I'd be interested to know the reason why
it was chosen against.

It seems like a faint code whiff to conflate the value of an element --
even if it can be boolean -- with the test being performed. Jake's concern
reinforces this for me. Why, for many element types, must the property be
tested one way and then for bools only, it's testable another. Sounds a
little like vector<bool> to me.

I agree it's daft that the user has to write such a pointless expression.
How about ready-made predicates which bridge the gap between the value of
the element and the criteria for the test, e.g. `is_true` and `is_false`
(which is essentially `logical_not`)? Then it's spelled out what property
of the element we're testing.

if (any_of(begin(v), end(v), is_true<>{}) { }

John

On Mon, 16 Dec 2019 at 21:15, Bernhard Manfred Gruber via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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!
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>