DIP 1030-- Named Arguments--Formal Assessment

[Jean-Louis Leroy]

On Thursday, 17 September 2020 at 13:23:38 UTC, Jean-Louis Leroy 
wrote:
> Actually, Parameters!origFun will carry storage classes, UDAs, 
> etc for all the parameters. And Parameters!origFun[0..1] (note 
> the two dots) will carry everything about the first parameter. 
> The trouble begins when, for some reason, you need to 
> manipulate the parameter at a finer level. For example, in 
> openmethods, I need to change the type while preserving 
> everything else.

(For the rest of this post, to make things clear, I will call 
Parameter declarations that appear inside the function 
definition, and Arguments the values that are passed to a 
function call).

I like named arguments. However, I would be greatly disappointed 
if:
1/ Parameters!origFun and Parameters!origFun[i..i+1] stopped 
working as well as they do now.
2/ The named arguments did not come with new traits (or at least 
is(__parameter) magic) to allow fully analyzing the parameters.

That being said, does the new feature imply any change in the 
*parameters* themselves? I.e. are there changes in the way the 
function is defined, not only in the way it is called?

I have not followed the discussion and just skimmed over the DIP 
now. I'm going to try to find time for this. However, at this 
point I have some hope that the DIP is not damaging in the way 
Mike thinks.