DIP 1019--Named Arguments Lite--Community Review Round 2

[Walter Bright]

I'll reiterate what I wrote for DIP1020 
https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html#N325627

---

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.