Hi,

On Sat, 2023-07-22 at 11:42 +0300, sasho648 via Std-Proposals wrote:
> I think a solution will be to outright ban such a conversion - where
> an lvalue array to pointer conversion will not be allowed in context
> where bool is expected.

I agree that it's not ideal, but there are a lot of existing code that
relies on the conversion of string literals to true. Mainly in the form
of:

assert(condition && "explanation");

https://codesearch.debian.net/search?q=assert%28.*%26%26+*%22.*%22%29&literal=0

C compatibility should also be considered.

clang seems to have -Wstring-conversion that finds this problematic
conversion, it also seems to exclude the assert use case.

Cheers,
Lénárd

>
> On Sat, Jul 22, 2023 at 11:39 AM sasho648 <sasho648_at_[hidden]> wrote:
> >
> > int arr[2];
> > bool test = arr;
> > bool teststr = "string";
> >
> >
> > Which I came across while having a function like this:
> >
> > void set_property(const char *name, const char *default_value);
> > void set_property_bool(const char*name, bool default_value);
> >
> > Where I thought the bool one was expecting a string as second
> > argument as well and so I wrote:
> >
> > set_property_bool("test", "true");
> >
> > Which compiled fine and even worked until I decided to change it
> > to:
> >
> > set_property_bool("test", "false");
> >
> > In my opinion such a conversion holds no value - since it has only
> > one outcome - and furthermore I think it's against C++ type safety
> > - and even furthermore I think currently it's only purpose is
> > obfuscation contests or creating hard to diagnose bugs as the case
> > I've shown above.