Shouldn't the fix be to make the argument types be a "bool adaptor"? such
that it can be constructed only with a book and provides a conversion
operators that converts to a bool. Pointers to bool conversation is
actually quite logical since a pointer can be null (not pointing to
anything) or not, such conversions help do that. How ever if you want to
avoid that for interfaces where this can cause issues to certain users then
a adaptor would indeed help to shrink the interface. Infact, bool for
interfaces should be a different adaptor types then simple books.
Like I want to be able to write
ptr? "Not null": "null"
But also avoid the issues that you faced

On Mon, 20 Apr 2026, 5:52 pm sasho648 via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> Not sure if you have the entire conversation since this is an old thread.
> But the previous example I had was:
>
>
>
> I agree I have had bug where I was doing:
>
> void set_property(const char *name, const char *default_value);
> void set_property_bool(const char*name, bool default_value);
>
> And so I was calling the first with:
>
> set_property("prop", "true")
>
> But then when I call the second version with
>
> set_property_bool("prop", "true")
>
> It compiles fine and even works as expected until I changed it to
>
> set_property_bool("prop", "false")
>
> And then I banged my head for a while.
>
> I also agree this was probably a bad design also but still.
>
> Which didn't have default parameters.
>
> And the topic is - should converson from pointer to bool like this be
> allowed.
>
>
> On Mon, Apr 20, 2026 at 3:40 PM Alejandro Colomar <
> une+cxx_std-proposals_at_[hidden]> wrote:
>
>> Hi,
>>
>> On 2026-04-20T15:25:08+0300, sasho648 via Std-Proposals wrote:
>> > Bump now I had:
>> >
>> > like:
>> >
>> > void f(int a, bool d = false);
>> >
>> > int f1(int a, int *p = nullptr);
>> >
>> > and I called:
>> >
>> > int *p;
>> >
>> > f(f1(2), p);
>> >
>> >
>> > It compiles and runs "fine" - except the behavior is totally unintended.
>> >
>> > It's evil in my opinion.
>>
>> C++ default parameters are evil, indeed.
>>
>> A better design for default parameters would be leaving the parameter
>> empty, which would make sure you don't misplace things.
>>
>> f(f1(2, p),);
>>
>> That extra comma makes sure you know what you're doing, by explicitly
>> asking for the default value. I do default parameters in C like that,
>> which can be easily implemented with macros.
>>
>> In general, I would recommend avoiding default parameters in C++.
>>
>> Maybe then you could propose allowing empty parameters when there's
>> a default parameter. That would be a safety improvement. Then
>> compilers could provide a warning flag for the old syntax. And with
>> time, even deprecate the old syntax.
>>
>> >
>> > Obviously I did a mistake putting the second parameter in the first call
>> > when I wanted it to be part of the f1 call.
>> >
>> > It never ever occurred to me until later on when I was checking this
>> part
>> > of the code for another thing.
>>
>>
>> Have a lovely day!
>> Alex
>>
>> >
>> > On Tue, May 13, 2025 at 12:16 AM Frederick Virchanza Gotham via
>> > Std-Proposals <std-proposals_at_[hidden]> wrote:
>> >
>> > >
>> > >
>> > > On Monday, May 12, 2025, Thiago Macieira wrote:
>> > >
>> > >>
>> > >>
>> > >> I do think deprecating the decaying of functions to function
>> pointers is
>> > >> the
>> > >> correct solution, but the chance of this happening before the entropy
>> > >> death of
>> > >> the universe are pretty slim.
>> > >>
>> > >>
>> > >
>> > > This is what Terry Davis did in his "Holy C" when he was writing
>> TempleOS.
>> > > He actually managed to turn C into a "just in time" language. I wish
>> he had
>> > > gotten the help he needed and gotten better, he was an extremely
>> talented
>> > > programmer and could have contributed greatly to our art with his
>> design
>> > > and implementation of programming languages and operating systems.
>> > >
>> > > https://en.wikipedia.org/wiki/TempleOS
>> > >
>> > >
>> > > --
>> > > 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
>>
>>
>> --
>> <https://www.alejandro-colomar.es>
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>