Jump to page: 1 211  
Page
Thread overview
DIP 1019--Named Arguments Lite--Community Review Round 1
Feb 15
JN
Feb 16
aliak
Feb 18
Rubn
Feb 17
Rubn
Feb 15
aliak
Feb 15
Ron J
Feb 16
aliak
Feb 16
aliak
Feb 16
Basile B.
Feb 15
Rubn
Feb 17
Cym13
Feb 17
Cym13
Feb 17
Rubn
Feb 17
Alex
Feb 17
Rubn
Feb 17
JN
Feb 17
Rubn
Feb 18
RazvanN
Feb 18
RazvanN
Feb 18
Seb
Feb 18
RazvanN
Feb 17
Rubn
Feb 18
SimonN
Feb 17
Elronnd
Feb 27
aliak
Mar 01
Rubn
Feb 27
JN
Feb 27
Daniel N
Feb 27
Dukc
February 15
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.
February 15
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":
>
> [...]

I'd add my library too as a possible library solution:

https://github.com/atilaneves/kwargs
February 15
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":

The fact that named arguments, as proposed, require both the caller *and* the callee to opt-in seems like it would make them almost useless in practice. Even if someone's willing to put in the effort of going through all of Phobos to figure out which functions should be annotated with @named, that still leaves all of the packages on code.dlang.org to deal with. Realistically, a lot of existing code will never be updated to work with this feature, even if it could benefit from it.

It's also a pretty unsightly wart for newcomers to D to first learn that D supports named arguments (hooray!), and then find out that no, they can't use them with <insert package here> (boo!), because the author of that package hasn't "said the magic word" to enable them.

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

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

I think named parameters should be opt-out rather then opt-in. It seems like a hassle for the developer to update your functions to support named arguments if it were to be opt-in. Making it opt-in for avoiding any code deprecation is simply not worth it. The benefit of readability by the callee greatly outweighs the cost of the code deprecation.

-Alex
 We have to take account of libraries that are rarely updated.
February 15
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":


- new function attribute is almost an automatic "no, thanks" from me
- misordering arguments, I don't like it either
February 15
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":

Wee! Named arguments :D

There's also another solution that was brought up by Simen.

Forum post: https://forum.dlang.org/post/ejnsqqebrjbwefjhagvg@forum.dlang.org
An implementation: https://github.com/aliak00/ddash/commit/911e3b580e7bbe06f43c258a2d1c78f97a9668c5#diff-6919882fdb1af168f0e5b90603414fae

Basically we have the following decision dimensions when allowing named parameters in APIs

Also I'm on the side of named parameters being the default and the API author deciding if their use is opt-out. But, that's a compile time breaking change to, basically, everything. So I guess that's out the window. So, there's probably a better chance with named parameters being opt-in.

1) I don't think it should be re-orderable because it allows callers to abuse APIs and not be used how the author (may have) intended:

void call(int me, int maybe) {}

call(maybe: 3, me: 2);
call(me: 2, maybe: 3);

Carly Ray would roll in her grave :p Also, who's calling who?!?

Also, it makes named overload resolution impossible should the need arise:

void call(int a, int b) {}
void call(int b, int a) {}

call(a: 3, b: 4); // ??

2) Then there's the issue of external names and internal names, as an API designer, I want to be able to specify an external name but also have a different internal identifier

move(T)(T from, T to);

Requires the awkward use of variables from and to in the function body. It's not the end of the world of course, but allowing external and internal variable naming gives allows for the best user experience, and code readability from both caller and API author:

move(T)(T from source, T to dest) {
  // implementation use source and dest
}

// caller uses from and to:
move(from: x, to: y);

3) Disallowing named arguments. In my experience this is especially useful for the first argument to a function.

move(x, to: y);

How does a ":" sound as an addition to the parameter list to be able to achieve all of these? By default, everything stays the same, i.e. no named parameters. If you add a ":" to your parameter then it *must* be called via named arguments by the caller. And if you have a second identifier after your first, then that one becomes the internal identifier (this can also be a separate DIP maybe in the future as it's additional)

move(T)(T :from, T :to);
move(a, b); // error
move(from: a, to: b); // ok

move(T)(T from, T :to);
move(a, b); // error
move(from: a, to: b); // error
move(a, to: b); // ok

Then there's the issue of default arguments:
* A default argument on an unnamed parameter can only come at the end.
* A default argument on a named parameter can go anywhere

void func(int a = 3, int :b)
func(b: 7); // ok

void func(int a = 3, int b); // error

void func(int :a = 7, int b, int :c = 4);

func(3); // ok

void func(int :a = 7, int b, int :c);

func(3, c: 8);

I think parameter lock in is as valid as a concern as function name lock in.

Also, I agree with everything Paul Backus has said in his response :) I'm just not so sure how feasible it'd be to allow an API author to force named arguments on their APIs and at the same time allow callers to use current libraries by using named arguments? I didn't think about it too much. But maybe they work together seamlessly?

Cheers,
- Ali


February 15
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":


I think the "Completeness" section contains some arguable points. The proposed solution doesn't take into account the cases where you need to partially skip default arguments.

Say, we have a function:

```void drawCircle(int x, int y, int radius, Border border = Border.Solid, Bg bg = Bg.Transparent)```

Then we want to call this function with default parameters except the background (bg).

The best way to do that would be:
```drawCircle(10, 10, 5, bg: Bg.Red);```

So you see that we omitted the "border" parameter.

However, the proposed solution forces us to do that:
```drawCircle(x: 10, y: 10, radius: 5, bg: Bg.Red);```

A lot more unnecessary typing.

Python, for example, allows us to mix both named and unnamed arguments, and thus effectively skip the default ones.
February 15
On Friday, 15 February 2019 at 13:49:04 UTC, Atila Neves 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":
>>
>> [...]
>
> I'd add my library too as a possible library solution:
>
> https://github.com/atilaneves/kwargs

I think that the solution proposed by Atila is better for the following reasons:
1. it is a library solution
2. allows both the user and the author of a library to specify functions with named parameters
3. it is very lightweight

But it is not enough for the following reasons:
1. Works only on templates (I'd like someone to explain to me why)
2. Is opinionated about using ad-hoc types to represent data (the opposite of http://wiki.c2.com/?PrimitiveObsession)

If there is a consensus against primitive obsessions I think it would be better to solve point 1 and leave the decision to library authors to implement named parameters function or users to make their wrappers. This opt-in behaviour is not different from what it is provided by the DIP
February 15
On Friday, 15 February 2019 at 17:38:23 UTC, Francesco Mecca wrote:
> On Friday, 15 February 2019 at 13:49:04 UTC, Atila Neves wrote:
>> [...]
>
> I think that the solution proposed by Atila is better for the following reasons:
> 1. it is a library solution
> 2. allows both the user and the author of a library to specify functions with named parameters
> 3. it is very lightweight
>
> [...]

You miss the other reason on why it is not enough: Compile time and run-time performance penalty.
-Alex
February 15
On Friday, 15 February 2019 at 17:43:52 UTC, 12345swordy wrote:
>
> You miss the other reason on why it is not enough: Compile time and run-time performance penalty.
> -Alex

Also, when doing a typo, rather than a nice error message "No named argument defined for function foo()", you'd probably get few screens of template vomit :)
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11