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.
