Reposting this back on the list.

On 2/2/23 09:11, Chris Ryan wrote:
> Andrey,
>
> I think you must realize there is a high resistance level to your idea
> of reusing the default keyword to cause the use of the defined default
> parameter. There are just way too many scenarios where it creates
> ambiguity in what signature you are really trying to invoke. The
> uniqueness of the signatures using default parameters relies upon the
> uniqueness of the argument types going left to right.

Not really, at least that's not how I understand how function calls work.

For a function call, first, a list of candidates is gathered, second,
the best candidate is chosen, and lastly, the defaults are applied for
the selected best candidate. At the first stage, the `default` arguments
are only used to discard candidates that do not have enough number of
arguments or do not have arguments with a default at the positions where
`default` is specified. `default` doesn't add new lookup namespaces and
hence no new candidates. At the second stage, `default` is simply
ignored, because it doesn't affect candidate rankings. Finally, at the
last stage, instead of only applying defaults for the tail unspecified
arguments, you would also apply defaults where `default` is specified in
the call expression.

> If you leave out
> (default) an argument to the left of an actual term the parse becomes
> just way too complex and undefined and ambiguous.

Sorry, I do not see the added ambiguity. Could you demonstrate it?

> I remember eons (and eons) ago people trying to do what you are talking
> about but instead of use the default keyword they just wanted to omit
> the parameter using an empty args (nothing between the commas ==default)
> Foo(,,,5);
>
> There are a number of ways around it as others have described. All are
> kind of a pain. Another flavor of a workaround is using std::bind<>.
> When you make the bind, you suppy what parameters you want to pass as
> 'default' and supply what should be passed as the other parameters (as
> _1, _2, _3).
>
> For the most part the era of using default params has long passed. I
> find it a weakness and question a design when it is used. As much as I
> hate API pollution I would rather see an overload that takes only the
> needed parameters (this also allows you to re-order the params), even if
> only to call the version with all the parameters. I think that
> many/most optimizing compilers can reduce the extra function indirection
> by inlining the 'adapter' method. Effectively making it look/act like
> it was using the default parameters. Just much less chance of any
> ambiguity or trying to call the wrong function.

Well, the reality is that default parameters (not only in functions) are
still widely used, including in the C++ standard library, and I don't
see this feature going away.

> Also eons ago in the dark ages of C++ some people thought that if you
> had a method that took a large number of parameters, they could save
> extra stack pushes by using default parameters thinking they would not
> be pushed. Yes they are all pushed, even the default parameters. But I
> am sure most everybody knows this now, right.

Right.