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, <> wrote:

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});
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")
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.).


Std-Proposals mailing list