1.Saying "default paremeters should be avoided" dosent sound right. A
better advice would be: "avoid default paremeters for pointers". Default
paremeters for values leads to notational convince, but of course, I should
not define a function named add_b_passsd_to_a
As : add_b_passsd_to_a(T a, T b={}); for a type T
In this case, I should change the notion that I am defining the notation
(by changing the name) for or remove the default argument.

2. Empty arguments already exist, infact you can use bind() to change the
notation of a function call for a specific function, or just provide
overloads. Simply allowing empty arguments is not a good idea. One might
say that empty arguments should be optional arguments which when missing
will lead to no code written when ever the argument is not used. The issue
with that is that, overloading already does that. Another technique could
be to simply make that argument be of a template type and the default for
that template type to be to provide the interface(using concepts) required
for that argument, that interface of course would do nothing since it's
literally am empty arguments and would return the safest dummy values
possible or throw an exception in areas where a proper value is expected.
This technique is the safest and I think a proposal for a facilities that
helps you produce a type like that for any type can help users produce
empty arguments. Such proposals would have to consider safe dummy return
values or when to throw an exception, and such proposal is probably the
closest you can get to avoiding what you faced.


On Mon, 20 Apr 2026, 5:40 pm Alejandro Colomar via Std-Proposals, <
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
>