A simpler way to fix this issue would be to simply allow "explicit"
arguments just like how we make constructors explicit.

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
>