DIP 1020--Named Parameters--Community Review Round 1

Walter Bright newshound2 at digitalmars.com
Sun Apr 7 03:09:23 UTC 2019


On 3/31/2019 5:33 AM, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 
> 1020, "Named Parameters":

Here's a much simpler proposal, based on the recognition that D already has 
named parameters:

   https://dlang.org/spec/struct.html#static_struct_init

and related:

   https://dlang.org/spec/hash-map.html#static_initialization
   https://dlang.org/spec/arrays.html#static-init-static

The only additional syntax would be allowing the equivalent of 
https://dlang.org/spec/hash-map.html#static_initialization in the argument list. 
Assignment of arguments to parameters would work the same way as assignments to 
fields.

As for the semantics, given this constraint, nothing needs to be invented, just 
discovered as necessary behavior. Consider:

    void snoopy(T t, int i, S s);     // A
    void snoopy(S s, int i = 0; T t); // B

and calling it:

    S s; T t; int i;
    snoopy(t, i, s); // A
    snoopy(s, i, t); // B
    snoopy(s, t); // error, neither A nor B match
    snoopy(t, s); // error, neither A nor B match
    snoopy(s:s, t:t, i:i); // error, ambiguous
    snoopy(s:s, t:t); // B
    snoopy(t:t, s:s); // B
    snoopy(t:t, i, s:s); // A
    snoopy(s:s, t:t, i); // A

I.e. function resolution is done by constructing an argument list separately for 
each function before testing it for matching. Of course, if the parameter 
name(s) don't match, the function doesn't match. If a parameter has no 
corresponding argument, and no default value, then the function doesn't match.

I don't see much point in requiring the names, preventing use of names, nor 
aliasing them. This has never been an issue for struct initializers.

One nice thing about this is the { } struct initialization syntax can be 
deprecated, as S(a:1, b:2) can replace it, and would be interchangeable with 
constructor syntax, making for a nice unification. (Like was done for array 
initialization.)

One issue would be order of evaluation: would the arguments be evaluated in the 
lexical order of the arguments, or the lexical order of the parameters?

Rationale:

Although this supports reordering, the real reason for naming is so one can have 
a function with a longish list of parameters, each with a reasonable default, 
and the user need only supply the arguments that matter for his use case. This 
is much more flexible than the current method of putting all the defaults at the 
end of the parameter list, and defaulting one means all the rest get defaulted.

A secondary reason is (again) for a longish list of parameters, when the user 
finds himself counting parameters to ensure they line up, then named parameters 
can be most helpful.


More information about the Digitalmars-d mailing list