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