DIP 1030--Named Arguments--Community Review Round 1 Discussion

[Steven Schveighoffer]

On 2/10/20 2:38 PM, Manu wrote:
> I do an immense amount of generative meta; generate wrappers, shims,
> bindings etc, which wrap existing functions.
> When the parameter names become part of the API, it means any such
> meta must pay extra attention to properly mirror the parameter names,
> and it must also carefully mirror the default args from the function
> it's wrapping.
> While most of my code takes care to do this anyway, there are cases
> where it's unnecessary and inconvenient. Some tasks can be completed
> with a tool like:
> 
>    ReturnType!originalFunction wrapper(alias
> originalFunction)(Parameters!originalFunction args)
>    {
>      // special sauce...
>      return originalFunction(args);
>    }
> 
> It is possible to write many forms of glue this way. If we must mirror
> the argument names and default arguments, you must fall back into
> string mixin territory, and the code to emit the proper prototype is
> complex and intensive.
> In a named-arguments world, shim's like the one I showed above are no
> longer valid where calling code would use named arguments.

This has convinced me (along with reading the subsequent thread) that we 
shouldn't introduce named parameters until we can solve this problem.

Whether it be via Timon's suggestion of having template tuples capture 
named parameters or some other mechanism.

And the is(typeof(fn) P == __parameters) idea isn't the right approach 
either. It intercepts the parameter names based on what the *target* is, 
not on how it was *called*. Templates make decisions based on what they 
are given.

-Steve