Syntax is not the hard part. There have been many syntaxes proposals with various pros and cons.

The hard part is do we even want them. There are at least 4 different things you can do with named parameters and some are bad style that are bad enough to kill the entire thing. Figure out what all the things that can be done with named parameters, then decide what cannot be better done some other way (perhaps write the proposal for those), only then should we find a solution to the remainder.

Good luck. If you push me I have some notes I could give you, but I lost interest when I realized how complex this seemingly simple and seemingly useful feature would be.

-- 
 Henry Miller
 hank_at_[hidden]
On Mon, Jul 29, 2019, at 10:17 AM, Maciej Cencora via Std-Proposals 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
>