On Thu, 2 Nov 2023 at 07:53, Chris Gary via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> .... 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.
>
>
> Its concise if used in conjunction with the Elvis operator:
> populateWith( oneVec ?: orAnother )
> printLine( errMsg ?: g_successMsg ) // these could be string_view or string
>
> The whole if ("") vs. if (""sv) is a complete red herring - those
>> don't appear in any generic context, and in fact those don't appear
>> anywhere.
>> Nobody writes that. Nobody is confused by it.
>>
>
> Seconding this.
>

I would dispute that; we use std::string_view() (i.e.
std::string_view(nullptr, 0)) as a sentinel value, distinct from ""sv.
Indeed, we would regard ""sv as truthy, since it is engaged in the sense
that its data() is non-null. (The same holds for std::span, of course).

If you really want contextual conversion to bool, wrap in a type that has
that conversion. C++ is the land of zero-overhead, after all. And in
generic code, use std::ranges::empty().

On Thu, Nov 2, 2023 at 4:03 AM Jonathan Wakely via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>>
>> 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"?)
>>
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>