February 16, 2019
On Friday, 15 February 2019 at 20:28:02 UTC, Paul Backus wrote:
> On Friday, 15 February 2019 at 18:32:52 UTC, Yuxuan Shui wrote:
>>> 5. Similarly, as already mentioned by somebody else, the DIP fails to explain interaction with function default arguments.
>>
>> I think it is reasonable to require a prefix of the parameters are specified.
>>
>> e.g. int fun(int a, int b = 1, int c = 2, int d = 3);
>>
>> The user can specify (a), (a, b), (a, b, c) or all of the parameters, and the arguments can be in any order.
>
> In my experience, one of the greatest benefits of argument re-ordering is that it lets you leave out optional arguments at the call site. For example, in Python, if you wanted to use the default value for every argument except `d`, you could write this:
>
>     fun(a=123, d=456)
>
> ...whereas with this proposal, you'd be required to needlessly repeat the default values for `a` and `b`:
>
>     fun(a: 123, d: 456, b: 1, c: 2);
>
> If this DIP isn't going to allow leaving out optional arguments in all cases, it might be better to simply forbid argument re-ordering entirely (or at least, to leave the issue for a future DIP).

Being able to leave out arguments would be hugely beneficial to the caller. You don't need reordering to achieve that though, the arguments can still be specified in the correct order while the ones with default values are left out:

https://swift.godbolt.org/z/Vhtouf


February 16, 2019
On Friday, 15 February 2019 at 21:05:38 UTC, Golden Rockefeller wrote:
> As another alternative, named parameters can be implemented using Tuple/tuple from the Phobos Library.

Tuples exist as an internal compiler type. The thing is just that there's no syntax for it. So what you think is a library thing is actually mostly compiler one.
Maybe the tuple DIP should be handled before the named parameter one maybe ?
February 16, 2019
On Friday, 15 February 2019 at 12:56:45 UTC, 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
>
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on March 1, or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment by the language maintainers.
>
> Please familiarize yourself with the documentation for the Community Review before participating.
>
> https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review
>
> Thanks in advance to all who participate.

With the struct initialization DIP there will come also named arguments complicity.

https://github.com/wilzbach/DIPs/blob/b1283b455b635d7dcbc2c871d2aa47cc67190059/DIPs/DIP1xxx-sw.md

Yes, the callee has to provide method/function  overload with a structure containing all arguments. But in theory Phobos could provide a mixin/template to make this task a one liner.

In my opinion this fits much nicer than introducing a new attribute.

Kind regards
Andre

February 16, 2019
On Friday, 15 February 2019 at 22:48:52 UTC, Rubn wrote:
> On Friday, 15 February 2019 at 12:56:45 UTC, Mike Parker wrote:
>> [...]
>
> drawRect(x: 0, y: 0, width: 1, height: 1);
> drawRect(width: 1, height: 1, x: 0, y: 0);
>
> The DIP doesn't state what order these are executed in. The spec states parameters are executed left to right. When you can rearrange the function arguments at the call site, is it going to call left to right as it is orangized at the call site, or left to right as according to as the function definition?
>

Good point. I will fix this in next revision.

Thanks.

February 16, 2019
On Friday, 15 February 2019 at 14:23:06 UTC, Paul Backus wrote:
> On Friday, 15 February 2019 at 12:56:45 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review for DIP 1019, "Named Arguments Lite":
>
> [snip]
>
> I understand that the intent is to avoid unintentional breakage, but this feature is already opt-in from the caller's side. If someone wants to write code that's robust against parameter name changes, they can do it by not using named arguments in the first place.

Named parameters have to be opt-in at both sides.

For the caller side, they can choose to not call the function with names so they can be robust against name changes (as you said).

For the callee side, opt into named parameter create extra responsibility for them (e.g. they need to create new prototypes if they want to change parameter names). So if they don't want this responsibility, they can choose to not opt-in

> And, as noted in the DIP itself, there are still opportunities for accidental breakage even with @named, when the caller fails to re-compile their code after a parameter name change.

I am not quite sure what you mean by this. A name change either changes the semantic of the parameters, in which case the caller won't realize their is a breakage until they recompile. But this kind of breakage is always intentional from the callee side. A pure parameter name change won't break anything even if caller doesn't recompile.

>
> Parameter lock-in is definitely a legitimate concern, but IMHO adding a neutered version of named arguments like this one to the language would be worse than not having named arguments at all.

If someone doesn't like this, they can come up with a DIP to deprecate the @named attribute in the future.
February 16, 2019
On Saturday, 16 February 2019 at 14:04:44 UTC, Yuxuan Shui wrote:

> If someone doesn't like this, they can come up with a DIP to deprecate the @named attribute in the future.

If many people don't like this, then what? That should be sufficient grounds of rejection of the DIP itself.

I *WILL* oppose this dip in it's entirely unless you remove the @named attribute requirement from it.

-Alex
February 16, 2019
On Saturday, 16 February 2019 at 14:04:44 UTC, Yuxuan Shui wrote:
> On Friday, 15 February 2019 at 14:23:06 UTC, Paul Backus wrote:
>> Parameter lock-in is definitely a legitimate concern, but IMHO adding a neutered version of named arguments like this one to the language would be worse than not having named arguments at all.
>
> If someone doesn't like this, they can come up with a DIP to deprecate the @named attribute in the future.

I don't think a DIP that makes the language worse should be accepted simply because someone, someday, may write a new DIP that makes it better again. And I would be very surprised if Walter and Andrei felt differently.
February 16, 2019
On Friday, 15 February 2019 at 12:56:45 UTC, 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 is the #1 missing language feature in my personal wish list. It allows drastically improving the readability of code in many situations. With it, we can also do away with the awful Flag!"enableSomething" enableSomething / Yes.enableSomething templates. So, thank you for working on this.

> For example, in one potential library-only solution, it is necessary to call functions like so:

> args!(add, a=>1, b=>1);

There is another big problem with this approach: you cannot do a=>a, b=>b etc. The compiler will pick up the fake lambda parameter instead of the variable from the outer scope. This is a pain because you will very often see fun(foo=foo, bar=bar) in idiomatic Python code.

> Opt-in: Calling a function with named arguments is opt-in on the callee side.

@named is not the best idea. I don't want to have to check every time if the library author remembered to slap @named on the function I want to use named arguments with. Making it opt-in will probably mean that there will be people who use it and those who don't, and libraries written by users who don't will just cause frustration by those who do; and, for people who do, they might as well just slap it on everything, further contributing to attribute bloat. Also, the decision to use named arguments depends as much on the function as on the call site (e.g. how important is code readability vs. terseness in that particular piece of code). I'd be just too tempted to patch the compiler to enable it for everything.

Generally, I do not buy the lock-in arguments, now or 10 years ago when Don shut the idea down the first time. I think it is enough to give library authors a way to provide aliases to old parameter names, so they have freedom to rename the parameters without breaking code using named arguments.

I'm not sure if forward arguments is the best approach for this, seems very brittle - you don't update all signatures correctly, and suddenly some users of your library get hit with linking errors. And, what about templated functions?

I think allowing alias in parameter lists would be worthwhile, e.g.:

void drawRect(int x, int y, int width, int height, alias w = width, alias h = height);

Bonus if "deprecated alias" is allowed and works as expected.

Sorry, I'm jumping late into the discussion, so the above might have been already discussed.

February 17, 2019
On Saturday, 16 February 2019 at 23:56:45 UTC, Vladimir Panteleev wrote:
> On Friday, 15 February 2019 at 12:56:45 UTC, 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 is the #1 missing language feature in my personal wish list. It allows drastically improving the readability of code in many situations. With it, we can also do away with the awful Flag!"enableSomething" enableSomething / Yes.enableSomething templates. So, thank you for working on this.
>
>> For example, in one potential library-only solution, it is necessary to call functions like so:
>
>> args!(add, a=>1, b=>1);
>
> There is another big problem with this approach: you cannot do a=>a, b=>b etc. The compiler will pick up the fake lambda parameter instead of the variable from the outer scope. This is a pain because you will very often see fun(foo=foo, bar=bar) in idiomatic Python code.

Good point.

>
>> Opt-in: Calling a function with named arguments is opt-in on the callee side.
>
> @named is not the best idea. I don't want to have to check every time if the library author remembered to slap @named on the function I want to use named arguments with. Making it opt-in will probably mean that there will be people who use it and those who don't, and libraries written by users who don't will just cause frustration by those who do; and, for people who do, they might as well just slap it on everything, further contributing to attribute bloat. Also, the decision to use named arguments depends as much on the function as on the call site (e.g. how important is code readability vs. terseness in that particular piece of code). I'd be just too tempted to patch the compiler to enable it for everything.

It's not my favorite either. But I feel it is the best we can do
at the moment.

>
> Generally, I do not buy the lock-in arguments, now or 10 years ago when Don shut the idea down the first time. I think it is enough to give library authors a way to provide aliases to old parameter names, so they have freedom to rename the parameters without breaking code using named arguments.
>
> I'm not sure if forward arguments is the best approach for this, seems very brittle - you don't update all signatures correctly, and suddenly some users of your library get hit with linking errors. And, what about templated functions?

I don't see why forward declaration won't work for templated functions.

And I don't quite understand why there might be linking problems. Can
you give an example?

>
> I think allowing alias in parameter lists would be worthwhile, e.g.:
>
> void drawRect(int x, int y, int width, int height, alias w = width, alias h = height);

So, there are a couple (two) problems with this:

1. the parameter list might just get longer and longer, making the documentation
   verbose and hard to read.
2. The user can use any combinations of the aliases (e.g. (x, y, w, height), (x, y, width, h) are all valid), this is not necessarily helpful to readability.

>
> Bonus if "deprecated alias" is allowed and works as expected.

deprecated forward declaration could work. I will make that explicit in the next revision of this DIP.

>
> Sorry, I'm jumping late into the discussion, so the above might have been already discussed.

You raised good points, thanks.


February 17, 2019
On Friday, 15 February 2019 at 20:35:14 UTC, Yuxuan Shui wrote:
> I am not saying "we should never break any code". I am deferring that decision to someone else. If someone want to make named parameters opt-out instead of opt-in, they can do so on top of this DIP. I am just not doing that in my proposal.

I think that, at least, you should include more details in the DIP text about what kind of breakage the @named attribute would prevent, how these breakages would otherwise occur, and what kind of situation would lead to them.

I personally think breakages are unlikely:

- The maintainer needs to export functions with argument names.
- The user has to explicitly use DIP-1019 and use named arguments.
- The maintainer has to change the argument names, without being aware of DIP-1019 and using your forward declaration workaround (and without being made aware of it by subsequent issues).
- Then the user gets an easy-to-fix compile error when they update their library.

In these cases, the user can always avoid using named arguments if there's a significant risk that named breakage occurs (eg if the library was written before DIP-1019).

Keep in mind that library maintainers can always opt out of named arguments by exporting prototypes with anonymous arguments:

    int foobar(int, float, string);

All-in-all, it's a trade-off with downsides either way, but I think being able to use named argument with any library made at any time far outweighs the breakage risks.