>
> .... 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.

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
>