On Wed, 1 Nov 2023 at 21:00, Arthur O'Dwyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Wed, Nov 1, 2023 at 3:09 PM Giuseppe D'Angelo via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On 01/11/2023 02:45, Hewill Kang via Std-Proposals wrote:
>> > Ranges adaptors *do* provide (explicit) operator bool since they all
>> > derived from ‘view_interface’.
>>
>> With this precedent, for better or worse, I'd say that the decision has
>> already been taken, and operator bool() should be added to all
>> containers. It makes very little sense that
>> if (vector)
>> doesn't compile, but
>> if (views::all(vector))
>> does.
>>
>
> For the record, I'm personally strongly against this proposal. It's bad
> enough that `optional<T>` is truthy; we really don't want `string` and
> `span` and so on also gaining truthiness. In a perfect world, we'd simply
> *remove* the implicit conversions from all the things that *currently*
> have them. (But of course we can't, because Hyrum's Law.)
> In particular, as others have pointed out, it would be insane for
> if ("")
> to be truthy but
> if (""sv)
> to be falsey.
>
> If you want to check something for emptiness, just check .empty().
> And if you've got a type that "can be empty" but fails to provide .empty()
> as a member function, file a DR! LWG is fixing iota_view
> <https://cplusplus.github.io/LWG/issue4001> as we speak, and my own P3016 fixes
> std::initializer_list
> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p3016r0.html>.
> But nota bene, "empty" is not the same thing as "disengaged" is not the
> same thing as "null" is not the same thing as "zero-valued." These are
> fundamentally distinct concepts, and it's important that they have distinct
> names in the C++ standard library.
>
>
Yeah, I don't like this proposal. Just because you *can* collapse some
property of containers to a simple true/false, doesn't mean we should add a
conversion to actually do that.

Should std::future have a conversion to bool for its valid() member? Or
maybe to check if it's ready (an API that's currently missing)?
Should std:: thread have a conversion to bool for joinable()?

As already pointed out, the Selection statements with initializer
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r1.html>
feature in C++17 makes it possible to test any arbitrary member function in
a condition. That means the advantage of a conversion to bool is just
slightly reduced verbosity, but at the cost of clarity (what exactly does
it mean for an arbitrary thing to be "true"?)