On Thursday, 21 March 2019 at 20:31:57 UTC, David Bennett wrote:
> On Sunday, 17 February 2019 at 21:04:23 UTC, Yuxuan Shui wrote:
>> After thinking about the feedback so far, I currently plan to make these changes to this DIP:
>>
>> ...
>
> Would you also be able to confirm how this DIP handles default arguments and templates?
> I think the DIP could use an example showing this off.

This DIP won't support template arguments.

And with my current plan this DIP probably won't help default arguments either.

>
> One of my almost dally 'is there no better way?' moments with D currently is default template arguments, for example to change throwErrors currently I need to do:
>
> ---
>
> T toString(T=string, bool SomeThing=true, bool throwErrors=true, S)(S value){return "";}
>
> auto foo = 123.toString!(string, true, false);
>
> ---
>
> Where as I think something like this would be better:
>
> ---
>
> auto foo = 123.toString!(throwErrors: false);
>
> ---

Yes, that would be better, but sadly that's out of the scope of this DIP.

On Monday, 4 March 2019 at 18:57:16 UTC, Olivier FAURE wrote:
> On Sunday, 3 March 2019 at 15:07:04 UTC, Joseph Rushton Wakeling wrote:
>> Well, since the current DIP is entirely opt-in from the function author side anyway, it's a bit of a moot point. I was responding rather to someone who was arguing that it should _not_ be opt in for function authors.
>
> My point was, the DIP should be opt-out, because even then library maintainers can always change argument names if they want to, without breaking code. And even if code does break, it's an extremely easy fix (as in, "change a few names until it compiles", not "refactor everything").
>
> Like, okay, I get that some people are opposed to the very idea of parameter names being important information to keep track of, but pragmatically, the costs of making named arguments the default are far outweighed by the benefits.

I agree that, having named arguments as the default would be better, _if_ we are designing a new language from ground up.

With D, even if we want to eventually make named arguments the default, it have to go through a deprecation path. IMHO, this is what a mature language should do.

On Friday, 22 March 2019 at 15:23:54 UTC, Yuxuan Shui wrote:
> I agree that, having named arguments as the default would be better, _if_ we are designing a new language from ground up.
>
> With D, even if we want to eventually make named arguments the default, it have to go through a deprecation path. IMHO, this is what a mature language should do.

Deprecation is typically used for changes to existing functionality that could break existing code. For example, the upcoming change to enable DIP 25 by default requires a deprecation process, because enabling DIP 25 will cause some code that currently works to fail to compile.

Named arguments, however, are a purely additive change to the language. They will not break any existing D code, because all existing D code uses positional arguments, and positional arguments will continue to work the same way they always have. Why, then, is a deprecation process necessary?

On Friday, 22 March 2019 at 15:18:09 UTC, Yuxuan Shui wrote:
> On Thursday, 21 March 2019 at 20:31:57 UTC, David Bennett wrote:
>> Would you also be able to confirm how this DIP handles default arguments and templates?
>> I think the DIP could use an example showing this off.
>
> This DIP won't support template arguments.
>
> And with my current plan this DIP probably won't help default arguments either.
>

That is unfortunate as its the part that gives me the most pain currently.

Almost so much as to make me feel like adding a 3rd named arguments DIP that only worked on default arguments.

On 2/15/19 7:56 AM, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1019, "Named Arguments Lite":
> 
> https://github.com/dlang/DIPs/blob/23ef47a94e0fdd5ddc4b2f6b2f4dcfd3c1f43aa6/DIPs/DIP1019.md 

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

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

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

* "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).

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

* "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 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).

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

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

On Thu, Jun 06, 2019 at 12:31:14PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> On 2/15/19 7:56 AM, Mike Parker wrote:
> > This is the feedback thread for the first round of Community Review for DIP 1019, "Named Arguments Lite":
> > 
> > https://github.com/dlang/DIPs/blob/23ef47a94e0fdd5ddc4b2f6b2f4dcfd3c1f43aa6/DIPs/DIP1019.md
[...]
> * "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).
> 
> * "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).
[...]

Yeah, these 2 points are also what greatly weakens this DIP, IMO, because they could be construed to be the raison d'etre of named arguments in the first place.  Not having them makes one wonder what's the point of this DIP in the first place.  As Amaury said in his DConf lightning talk, we don't want 95% features (or in this case, more like 50% features -- halfway there but missing major benefits of having named arguments in the first place). We want 100% features that provide core benefits, without being crippled in some way that makes them useless in non-trivial cases.


T

-- 
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth

On Friday, 15 February 2019 at 15:10:28 UTC, Guillaume Piolat wrote:

> - misordering arguments, I don't like it either

Yeah, that bothers me, too.

OP:
And how would a feature like this work with variable-length argument lists?

As for the whole named arguments thing, I like the concept, but I'm still mulling over whether I connect with it in practice.

I'd just like to point out to everyone that this thread is for the first round of DIP 1019's community review. Andrei appears to have reviewed the correct version of the DIP, he simply misplaced his feedback. The second round is going on here:

https://forum.dlang.org/thread/sbkftyukevoydivapumm@forum.dlang.org

Best if we keep all the discussion in one place.