So you mean the same way arrays can be bound to references but instead here
making it that arrays fail to bind to bool. I think this would be a good
solution too.

On Sat, Jul 22, 2023 at 1:03 PM Lénárd Szolnoki via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hi,
>
> On Sat, 2023-07-22 at 10:35 +0100, Jonathan Wakely wrote:
> >
> >
> > On Sat, 22 Jul 2023, 10:08 Lénárd Szolnoki via Std-Proposals,
> > <std-proposals_at_[hidden]> wrote:
> > > 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");
> >
> >
> > Would this work if we made arrays contextually convertible to bool?
>
> Good idea, this works.
>
> > I can't think of any other valid uses for "is this array a null
> > pointer? No of course it isn't" (and this one is a bit of a "clever"
> > hack anyway).
>
> I agree that it's on the clever side, but it's working around a real
> shortcoming of assert. Maybe assert could be improved to accept an
> optional explanation. But this doesn't help with not breaking existing
> code, where this seemingly grew into a possibly questionable idiom.
>
> An alternate idiom could have used the comma operator to discard the
> "explanation", but I never saw that one being used. Probably needs
> extra parenthesis as well to play well with the assert macro.
>
> > >
> > >
> 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.
> > >
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>