This is essentially what I was suggesting when the topic appeared last
year, with the exception that I suggested it be implied by the standard
function definition syntax and that it automatically generated the struct
version. Personally I prefer your approach because I'm inclined towards
opt-in named parameters for some time to allow maintainers of large
libraries to get their names straight, and also allows those who maintain
libraries with ugly parameter names by design (e.g. standard library) to
make friendlier wrappers.

Its not perfect, though. It passes DRY violation onto the compiler and
impacts compiled library size, and it also means that you end up with
possibly ambiguous calls if a version accepting a struct of the same layout
is already provided.

I fear my position is thus paradoxical. Opt in must surely have these same
issues, at least to some extent, no matter how we do it.

On Mon, 29 Jul 2019, 16:17 Maciej Cencora via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> Hi,
>
> here is an idea on how to support named parameters in backward compatible
> way:
>
> allow single anonymous struct definition inside func parameter signature:
> void foo(struct { bool param1; int param2; })
> {
> impl(param1, param2);
> }
>
> The signature:
> void foo(struct { bool param1; int param2; })
> is equivalent to:
> void foo(bool param1, int param2).
>
> with the added benefit that it supports named parameters via designated
> initializers:
> foo({.param1 = false, .param2 = 10});
> or
> foo(false, 10);
>
> Designated initialization rules could be relaxed for this specific case to
> allow initializers be in different order than declared.
>
> This won't brake existing code, and we can introduce named params for
> existing API via function alias mechanism in backward compatible way:
>
> assuming we have POSIX fopen:
> int fopen(const char* pathname, const char* mode);
>
> we standardize new function alias:
> using fopen(struct { const char* pathname; const char* mode;}) =
> fopen(pathname, mode);
>
> and now user can do:
> fopen("/my/file", "w")
> or
> fopen({.pathname = "/my/file", .mode = "w"});
>
>
> Function alias mechanism could be re-used in many more scenarios (e.g.
> during refactoring, when changing func name, or re-ordering parameters,
> etc.).
>
>
> Thoughts?
>
> Regards,
> Maciej
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>