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

[Yuxuan Shui]

On Thursday, 6 June 2019 at 20:04:15 UTC, Walter Bright wrote:
> 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.

I don't necessarily see any problems with this proposal. (Also, I 
think this is a superset of my DIP). But I don't think what you 
have written here covers all of the nitty-gritty that could arise 
if your proposal is implemented.

I don't have a really strong example off the top of head, but I 
have a couple of small things that need clarification:

1. (Clearly function overloading is affected, but) is name 
mangling also affected?
2. What about declarations in .di files?
3. What about function declarations with parameter names 
different from the definition?

> 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.

There is at least on difference here: structs can have private 
members.