So Jonathan brought up a very good point against named arguments [0], that D is not consistent at all when it comes to argument names. E.g. range functions that have a parameter "r" as opposed to parameter "range" (and there're more).

So if named arguments are accepted, from that release onwards people will start writing:

choose(condition: true, r1: a, r2: b)
radial(r: a);
take(input: a, n: 3);
takeExactly(range: a, n: 3);
takeOne(source: a);

There're probably a tonne of these with different parameter names for a range. It'll be a mess. And then any changes will be breaking.

Should we maybe go through and make parameter names consistent where they obviously can be before named parameters gets to get in (should it get in)? e.g.:

choose(condition: true, range1: a, range2: b)
radial(range: a);
take(range: a, n: 3);
takeExactly(range: a, n: 3);
takeOne(range: a);

[0] https://forum.dlang.org/post/mailman.138.1566856133.19826.digitalmars-d@puremagic.com

On Monday, August 26, 2019 4:19:38 PM MDT aliak via Digitalmars-d wrote:
> So Jonathan brought up a very good point against named arguments [0], that D is not consistent at all when it comes to argument names. E.g. range functions that have a parameter "r" as opposed to parameter "range" (and there're more).
>
> So if named arguments are accepted, from that release onwards people will start writing:
>
> choose(condition: true, r1: a, r2: b)
> radial(r: a);
> take(input: a, n: 3);
> takeExactly(range: a, n: 3);
> takeOne(source: a);
>
> There're probably a tonne of these with different parameter names for a range. It'll be a mess. And then any changes will be breaking.
>
> Should we maybe go through and make parameter names consistent where they obviously can be before named parameters gets to get in (should it get in)? e.g.:
>
> choose(condition: true, range1: a, range2: b)
> radial(range: a);
> take(range: a, n: 3);
> takeExactly(range: a, n: 3);
> takeOne(range: a);
>
> [0] https://forum.dlang.org/post/mailman.138.1566856133.19826.digitalmars-d@pu remagic.com

This is exactly one of the reasons why I think that named arguments are a terrible idea. Now, we get to bikeshed about what the "official" name is that we should be naming all of these range parameters in order to be consistent and how we should deal with naming them when there are multiple range arguments. None of this mattered previously. As long as the name was reasonable, it was irrelevant, and even then, it really only mattered for documentation purposes and for making the function internals reasonable to maintain.

- Jonathan M Davis

On Mon, 26 Aug 2019 22:19:38 +0000, aliak wrote:
> 
> Should we maybe go through and make parameter names consistent where they obviously can be before named parameters gets to get in (should it get in)? e.g.:
> 
> choose(condition: true, range1: a, range2: b)
> radial(range: a);
> take(range: a, n: 3);
> takeExactly(range: a, n: 3);
> takeOne(range: a);

I can't see any place where I'd use the parameter name for a range, so r/ range/r1/etc. wouldn't matter. My range variable name is the documentation, or it's a literal array in a unittest. Based on what I've read of others' code, that's typical; and range functions tend to be small and named for what they do, so are self-documenting.

---
arr = myRange.sort!((a, b) => a > b)
    .takeExactly(10) // .takeExactly(number: 10) doesn't aid readability,
    .group           //  so why bother?
    .assocArray;
---

Most of the time in other languages a named parameter will document a literal argument or allow skipping parameters with default values. It would be a good idea to skim Phobos to name-check, but I don't think it will require a really large number of renames since most parameters realistically won't be passed via their names.

--Ryan

This is a good example of why named arguments should be opt-in.
Unless an API was designed to use it, you are overriding the intent of the API maker and that won't give a good experience to the user.

On Monday, 26 August 2019 at 23:46:51 UTC, Jonathan M Davis wrote:
>
> This is exactly one of the reasons why I think that named arguments are a terrible idea. Now, we get to bikeshed about what the "official" name is that we should be naming all of these range parameters in order to be consistent and how we should deal with naming them when there are multiple range arguments. None of this mattered previously. As long as the name was reasonable, it was irrelevant, and even then, it really only mattered for documentation purposes and for making the function internals reasonable to maintain.

Yes I understand you don't want named parameters :) I think the benefits far outweigh this negative (plus I agree with rikki). But if they do go in without opt-in, then my question still stands?

>
> - Jonathan M Davis

On Tuesday, 27 August 2019 at 02:09:55 UTC, rjframe wrote:
> On Mon, 26 Aug 2019 22:19:38 +0000, aliak wrote:
>> [...]
>
> I can't see any place where I'd use the parameter name for a range, so r/ range/r1/etc. wouldn't matter. My range variable name is the documentation, or it's a literal array in a unittest. Based on what I've read of others' code, that's typical; and range functions tend to be small and named for what they do, so are self-documenting.
>
> ---
> arr = myRange.sort!((a, b) => a > b)
>     .takeExactly(10) // .takeExactly(number: 10) doesn't aid readability,
>     .group           //  so why bother?
>     .assocArray;
> ---
>
> Most of the time in other languages a named parameter will document a literal argument or allow skipping parameters with default values. It would be a good idea to skim Phobos to name-check, but I don't think it will require a really large number of renames since most parameters realistically won't be passed via their names.
>
> --Ryan

1) I agree about ranges, most will probably just use it in a way that it doesn't matter
2) But, if there's a feature it will be used. Always.
3) Won't hurt to make the arguments even for ranges consistent.

On Tuesday, August 27, 2019 1:09:44 AM MDT aliak via Digitalmars-d wrote:
> On Monday, 26 August 2019 at 23:46:51 UTC, Jonathan M Davis wrote:
> > This is exactly one of the reasons why I think that named arguments are a terrible idea. Now, we get to bikeshed about what the "official" name is that we should be naming all of these range parameters in order to be consistent and how we should deal with naming them when there are multiple range arguments. None of this mattered previously. As long as the name was reasonable, it was irrelevant, and even then, it really only mattered for documentation purposes and for making the function internals reasonable to maintain.
>
> Yes I understand you don't want named parameters :) I think the benefits far outweigh this negative (plus I agree with rikki). But if they do go in without opt-in, then my question still stands?

If we don't end up with named arguments in the language, then renaming the parameters in Phobos is a waste of time and resources - not to mention a lot of pointless bikeshedding over what the names should be. If we do get named parameters, the DIP will almost certainly be accepted before anyone implements the feature (potentially way before anyone implements it, since DIPs that aren't implemented by the person proposing them tend to not be implemented particularly quickly), so we can worry about renaming stuff then.

- Jonathan M Davis

On Monday, 26 August 2019 at 22:19:38 UTC, aliak wrote:
> So if named arguments are accepted, from that release onwards people will start writing:

Named arguments cover a specific usecase. The most common one is function calls with multiple optional arguments. After the DIP goes in, I don't see people using named arguments for everything.

On Tuesday, 27 August 2019 at 07:35:32 UTC, Jonathan M Davis wrote:
> If we don't end up with named arguments in the language, then renaming the parameters in Phobos is a waste of time and resources - not to mention a lot of pointless bikeshedding over what the names should be. If we do get named parameters, the DIP will almost certainly be accepted before anyone implements the feature (potentially way before anyone implements it, since DIPs that aren't implemented by the person proposing them tend to not be implemented particularly quickly), so we can worry about renaming stuff then.
>
> - Jonathan M Davis

Fair enough.

On Tuesday, 27 August 2019 at 08:59:06 UTC, JN wrote:
> On Monday, 26 August 2019 at 22:19:38 UTC, aliak wrote:
>> So if named arguments are accepted, from that release onwards people will start writing:
>
> Named arguments cover a specific usecase. The most common one is function calls with multiple optional arguments. After the DIP goes in, I don't see people using named arguments for everything.

You'd be surprised what people will use named arguments for.