Hi Muneem,

On 2026-04-20T17:51:55+0500, Muneem via Std-Proposals wrote:
> 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,

Default parameters are always dangerous. Pointers or not pointers, the
story doesn't change much. They should really be avoided.

See <https://lore.kernel.org/lkml/abhGS0n_RsUG97Ni_at_[hidden]/> for a macro
in the Linux kernel that was made unnecessarily dangerous by adding a
default parameter.

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

Overloads are also evil; possibly more than default parameters.
They're, IMO, the worst part of C++.

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

No code written where? You mean that translation should halt? Also,
what you you mean that the argument is not used?

> The issue
> with that is that, overloading already does that.

Which is another feature to avoid entirely.

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

Would you mind using some paragraphs? That wall of text is hard to
read. Also, some examples of what you're talking about would help.


Have a lovely day!
Alex

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

> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

-- 
<https://www.alejandro-colomar.es>