DIP 1030-- Named Arguments--Formal Assessment
jl at leroy.nyc
Thu Sep 17 13:42:47 UTC 2020
On Thursday, 17 September 2020 at 13:23:38 UTC, Jean-Louis Leroy
> 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
I like named arguments. However, I would be greatly disappointed
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
More information about the Digitalmars-d-announce