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

[Yuxuan Shui]

On Saturday, 8 June 2019 at 06:44:56 UTC, Andrei Alexandrescu 
wrote:
> On 6/5/19 9:03 AM, Mike Parker wrote:
>> This is the feedback thread for the second round of Community 
>> Review for DIP 1019, "Named Arguments Lite":
>> 
>> https://github.com/dlang/DIPs/blob/9c9cc39246de4c449fe1e6cb6b27f7e426ff1eb9/DIPs/DIP1019.md
>
> [initially posted in the wrong thread, pasting here for 
> conformity]

Thanks for the feedback!

I will try to address some of your points.

>
>
> Things that I think would make this DIP stronger:
>
> * The presence of the feature in other programming languages 
> belongs in "rationale" if also the rationale pertaining to 
> those other languages is present. Otherwise it's argument by 
> majority. Normally "rationale" would stand on its own (possibly 
> using examples drawn/inspired from other languages) and mention 
> of other languages would go in the "related work" section 
> (which presently is missing).
>
> (@Michael we need to make "Related Work" a required section.)

Will do.

>
> * The example with "CalculateProduct(values, 7, false, null);" 
> in the rationale should be completed with the best-of-the-breed 
> solution in the current D language, i.e. using Flag. Currently 
> Flag is not being discussed at all and it should because it is 
> a workaround to named parameters (however insufficient as the 
> proposal might argue).

Will do.

>
> * The argument with repurposing argument is weak because code 
> that doesn't use named parameters would be broken anyway, which 
> makes the idea of repurposing parameters bad to start with. I 
> suggest it be dropped, or mentioned later as a perk of named 
> parameters.

The point is named parameters prevents silent breakage. Which I 
think is a significant benefit.

Of course, code that do not use named parameters won't get the 
benefit of named parameters. This is just the natural of things 
and shouldn't be used as a point against the point.

>
> * "The relevance of forward declarations will become clear 
> later." -> "Section xyz clarifies the relevance of forward 
> declarations."
>
> * "Named arguments proposed by this DIP have no effect on the 
> ordering of arguments in function calls." Related work will in 
> all likelihood reveal that reordering arguments in large 
> argument lists is a key advantage of named arguments. Not 
> availing ourselves of that advantage is a serious issue that 
> weakens the proposal. It must explain why it is not possible to 
> allow reordering of arguments (or better yet work out the 
> mechanics to allow it).

Reordering is definitely a very important feature. However, this 
proposal is not going to be the last DIP about named parameters, 
as is stressed in the proposal itself.

Generally, I think incremental improvements should be allowed.

>
> * "Named arguments proposed by this DIP do not allow default 
> parameters to be skipped." Not sure what "skipped" means in 
> context; I assume it means some defaulted arguments would be 
> left unspecified and other following them would be specified 
> with non-default values. My understanding is that this is 
> another key advantage of named arguments in related work - 
> typically complex functions with large argument lists like 
> CreateWindow, CreateArchive etc. would have many arguments 
> defaulted to reasonable values, which then the caller can pick 
> and choose which to customize. I assume a large part of what 
> makes Python APIs so friendly is this ability. The DIP should 
> explain why this is not desirable or achievable for the D 
> language (or again better yet make it just work).

Same as the above one.

>
> * "Variadic arguments can be labeled with the name of the 
> variadic parameter and a subscript." seems to have little value 
> if there's only one variadic per function and all indexes must 
> be specified in order. The DIP should explain why this feature 
> (the index can be any compile-time expression... right?) is 
> useful.

index can only be integer literals, as is specified in the 
"Grammar changes" section.

This exists to avoid confusion that might arise from labeling 
multiple arguments with the same name.

>
> * "If a function is defined with some of its parameter names 
> omitted, arguments to those parameters can labeled with an 
> empty name." The utility of this should be explained.

This feature is here for completeness and consistency, so there 
is not a case where an argument cannot be labeled.

Unless there is a strong disadvantage of allowing this, I think 
this should stay.

>
> * "This seems to be the biggest concern among people who are 
> against named arguments." This is vague and nonscientific and 
> has no place in a DIP. Who are those (does it even matter), 
> where are the relevant exchanges, how did the author arrive at 
> the conclusion that this is the biggest concern. The concern 
> should be discussed at face value and if appropriate rebutted 
> soundly with an analysis of the tradeoff (I assume it's not 
> "all bad" vs "all good" but more like pros and cons).

Good point.

>
> * "Allow calling the same function with a different set of 
> parameter names." The advantage of this seems to be backward 
> compatibility, but it endorses a technique that is questionable 
> in the first place.

Can you elaborate why is this questionable?

>
> * "This DIP does not prohibit future proposals for adding 
> parameter reordering, partially-specified parameter names with 
> reordering, named template parameters, omission of default 
> arguments by using named arguments, and other similar things." 
> The problem here is that all of these (easily anticipated as 
> desirable) weaken the DIP by their absence from it.

The point I want to make it that you shouldn't compare this DIP 
to some idealized, optimal DIP you imagined. You should evaluate 
it by comparing it to what we have now. Especially for a DIP that 
allows (anticipates, even) further improvements.

If this DIP is a net improvement, and no major concern exists 
against it, I don't see why it cannot be accepted just because it 
doesn't give us all the things we want at once.