On Thursday, 6 June 2019 at 20:04:09 UTC, 12345swordy wrote:
> On Thursday, 6 June 2019 at 19:17:38 UTC, Jonathan Marler wrote:
>> [...]
>
> This has been brought up in the discussion regarding named arguments for DIP1020 (more specifically the @named attribute) and so far I am not convinced that this is an issue that needs to be address, and found it be be overblown given that we have powerful rename tools at this day of age.
>
> Having it "opt-in" have it own downsides as the users have to request library developers to add the capability to their libraries. Among many other issues that were brought up and discuss with "opt-in"ing DIP1020.
>
> Alex

Rename tools are irrelevant as they only work when you're in a single project.  Exposing the parameters names of every function would mean the we would pretty much need to keep all the parameter names in every function in druntime/phobos, otherwise we would break compatibility.

Far to high of a cost just to allow some cases to be more readable.  However, if you make it opt-in, then you don't have to pay that cost for EVERY function, you only increase coupling in the cases that make sense.

On Thursday, 6 June 2019 at 20:10:06 UTC, Jonathan Marler wrote:
> On Thursday, 6 June 2019 at 20:04:09 UTC, 12345swordy wrote:
>> On Thursday, 6 June 2019 at 19:17:38 UTC, Jonathan Marler wrote:
>>> [...]
>>
>> This has been brought up in the discussion regarding named arguments for DIP1020 (more specifically the @named attribute) and so far I am not convinced that this is an issue that needs to be address, and found it be be overblown given that we have powerful rename tools at this day of age.
>>
>> Having it "opt-in" have it own downsides as the users have to request library developers to add the capability to their libraries. Among many other issues that were brought up and discuss with "opt-in"ing DIP1020.
>>
>> Alex
>
> Rename tools are irrelevant as they only work when you're in a single project.
No, they are not irrelevant, that what C# developers such as myself use when the named argument name has been change.

>  Exposing the parameters names of every function would mean the we would pretty much need to keep all the parameter names in every function in druntime/phobos, otherwise we would break compatibility.

We have a deprecated attribute for a very good reason.

> Far to high of a cost just to allow some cases to be more readable.

I strongly reject this claim, due to the lack to evidence. I encounter no apocalypse scenario when it comes to unable to named arguments in the C# community which you can not opt it out.

Alex

On Thursday, 6 June 2019 at 20:10:06 UTC, Jonathan Marler wrote:
> Far to high of a cost just to allow some cases to be more readable.  However, if you make it opt-in, then you don't have to pay that cost for EVERY function, you only increase coupling in the cases that make sense.

Making it optional makes it useless. Name the programming languages that implement named parameters this way, and I'll give a giant list of ones that don't. You can make this exact argument for basically structs and everything else. When you use a library you are at the mercy of it's owner. I've seen some people maintain an API that just literally changed the style so basically every single line that used that API now had to be updated. It was a minor version too 3.0 -> 3.1. Let the user decide when those cases are for themselves, and they do so knowing the risk, like with everything else they may have to update their code to match.

There's already enough attributes, we shouldn't be adding more needlessly. I don't think this is a good enough reason to.

On Thursday, 6 June 2019 at 20:22:17 UTC, 12345swordy wrote:

> I strongly reject this claim, due to the lack to evidence. I encounter no apocalypse scenario when it comes to unable to named arguments in the C# community which you can not opt it out.
>
> Alex

* I encounter no apocalypse scenario when it comes to
 unable to opt out named arguments in the C# community.

Grammar fix.

On Thursday, 6 June 2019 at 20:04:15 UTC, Walter Bright wrote:
>    discovered as necessary behavior. Consider:
>
>     void snoopy(T t, int i, S s);     // A
>     void snoopy(S s, int i = 0; T t); // B
>
> and calling it:
>
>     S s; T t; int i;
>     snoopy(t, i, s); // A
>     snoopy(s, i, t); // B
>     snoopy(s, t); // error, neither A nor B match
>     snoopy(t, s); // error, neither A nor B match
>     snoopy(s:s, t:t, i:i); // error, ambiguous
>     snoopy(s:s, t:t); // B
>     snoopy(t:t, s:s); // B
>     snoopy(t:t, i, s:s); // A
>     snoopy(s:s, t:t, i); // A

Trying to understand why the last two call A and are not ambiguous?

> One issue would be order of evaluation: would the arguments be evaluated in the
> lexical order of the arguments, or the lexical order of the parameters?

Arguments would provide consistency but parameters feel more intuitive from a user perspective. But yeah, hard to say!

On Thursday, June 6, 2019 1:50:09 PM MDT FeepingCreature via Digitalmars-d wrote:
> On Thursday, 6 June 2019 at 19:17:38 UTC, Jonathan Marler wrote:
> > There's a big issue with this DIP.  It immediately allows any function call to increase coupling with the corresponding function definition with no way to disable it.
>
> I just want to explicitly note that increasing coupling between the call site and the function definition is the entire point of named parameters.

Which is precisely why I really hope that no named parameter DIP is ever accepted. It means that suddenly the parameter names are part of the API, meaning that there's yet another point where you have to worry about breaking user code and another point where you have to worry about naming things really well and where people will then bikeshed names. E.G. right now, there is zero attempt in Phobos to name all range parameters the same, and there's no need to, but if named parameters become a thing (especially without requiring that the function be annotated to allow them), then suddenly, we have naming problems all over the place when we didn't before, because the naming isn't consistent.

IMHO, named parameters are rarely useful with well-written code. They're primarily of benefit when you have a lot of function parameters, which is bad design. And they're a particularly odd design choice in a language where you're allowed to have interface files that don't even have to provide parameter names let alone make them match the ones in the .d file.

But I suppose that there isn't much point in my expressing how much I hate DIPs like this in review threads, since such threads are really just for helping to improve the DIP, not vote it down. The decision on that is solely up to Walter and Andrei (or Atila now, I guess).

- Jonathan M Davis

On Thursday, 6 June 2019 at 20:22:17 UTC, 12345swordy wrote:
> On Thursday, 6 June 2019 at 20:10:06 UTC, Jonathan Marler wrote:
>> On Thursday, 6 June 2019 at 20:04:09 UTC, 12345swordy wrote:
>>> On Thursday, 6 June 2019 at 19:17:38 UTC, Jonathan Marler wrote:
>>>> [...]
>>>
>>> This has been brought up in the discussion regarding named arguments for DIP1020 (more specifically the @named attribute) and so far I am not convinced that this is an issue that needs to be address, and found it be be overblown given that we have powerful rename tools at this day of age.
>>>
>>> Having it "opt-in" have it own downsides as the users have to request library developers to add the capability to their libraries. Among many other issues that were brought up and discuss with "opt-in"ing DIP1020.
>>>
>>> Alex
>>
>> Rename tools are irrelevant as they only work when you're in a single project.
> No, they are not irrelevant, that what C# developers such as myself use when the named argument name has been change.
>

You missed the point.  I'm talking about libraries (like druntime and phobos) now have all their function parameters exposed.  If they need to change them, you can't use a replace tool on every single D project in the world that depends on DRuntime and Phobos.  Thus, replace tools are irrelevant in this case.

>>  Exposing the parameters names of every function would mean the we would pretty much need to keep all the parameter names in every function in druntime/phobos, otherwise we would break compatibility.
>
> We have a deprecated attribute for a very good reason.

Yes there are solutions, but you have to weigh the cost with the benefit.  There are not that many functions that will benefit from using named parameters.  I'd guess around 15% of all functions would use them, and you're breaking encapsulation with all 100% of functions to accommodate the 15%.  It's a high cost compared to the benefit.

However, if you make it "opt-in", then you don't have to pay that high cost.

>
>> Far to high of a cost just to allow some cases to be more readable.
>
> I strongly reject this claim, due to the lack to evidence. I encounter no apocalypse scenario when it comes to unable to named arguments in the C# community which you can not opt it out.
>

It's the same argument for having private fields in classes and structs. If you don't understand the benefits of encapsulation then I'm not sure what to say.  The more coupling and internals you expose, the more opportunity to break your interface.  And because functions are such a big part of D, you're making the language overall much more brittle than it was before.

On Thursday, 6 June 2019 at 21:46:14 UTC, Jonathan M Davis wrote:
> On Thursday, June 6, 2019 1:50:09 PM MDT FeepingCreature via Digitalmars-d wrote:
>> On Thursday, 6 June 2019 at 19:17:38 UTC, Jonathan Marler wrote:
>> > There's a big issue with this DIP.  It immediately allows any function call to increase coupling with the corresponding function definition with no way to disable it.
>>
>> I just want to explicitly note that increasing coupling between the call site and the function definition is the entire point of named parameters.
>
> Which is precisely why I really hope that no named parameter DIP is ever accepted. It means that suddenly the parameter names are part of the API, meaning that there's yet another point where you have to worry about breaking user code and another point where you have to worry about naming things really well and where people will then bikeshed names. E.G. right now, there is zero attempt in Phobos to name all range parameters the same, and there's no need to, but if named parameters become a thing (especially without requiring that the function be annotated to allow them), then suddenly, we have naming problems all over the place when we didn't before, because the naming isn't consistent.

Exactly.

>
> IMHO, named parameters are rarely useful with well-written code. They're primarily of benefit when you have a lot of function parameters, which is bad design. And they're a particularly odd design choice in a language where you're allowed to have interface files that don't even have to provide parameter names let alone make them match the ones in the .d file.

I mostly agree.  Though I estimate they are sometimes useful even with a well-written interface, but, it is more rare.  Hence why I think an "opt-in" version would work well.  Just add "public" to the parameters you want to expose the names of.  Same semantics as fields of classes and structs.  Default to private, add "public" if you want the caller to see the name.

void foo(T t, public bool log);

foo(t, log: true);

>
> But I suppose that there isn't much point in my expressing how much I hate DIPs like this in review threads, since such threads are really just for helping to improve the DIP, not vote it down. The decision on that is solely up to Walter and Andrei (or Atila now, I guess).
>

But I'm sure they read these threads when reviewing.

On Thursday, 6 June 2019 at 22:19:46 UTC, Jonathan Marler wrote:
> If they need to change them

Why would they need to change the name of a function argument anyway?

Note that the name is already exposed in the documentation too, as well as by existing reflection (I, among others, have written named param libraries already, for example).

> I'd guess around 15% of all functions would use them

I'd probably not use it myself so I'm meh on having it in the language... but I don't think the breakage is a big deal. You can just not use it in your code and be protected against arbitrary changes.

Though if the name changes, it might indicate a change in meaning of the param too, so maybe breakage is a good thing.

On Thursday, 6 June 2019 at 20:25:32 UTC, Exil wrote:
> On Thursday, 6 June 2019 at 20:10:06 UTC, Jonathan Marler wrote:
>> Far to high of a cost just to allow some cases to be more readable.  However, if you make it opt-in, then you don't have to pay that cost for EVERY function, you only increase coupling in the cases that make sense.
>
> Making it optional makes it useless. Name the programming languages that implement named parameters this way, and I'll give a giant list of ones that don't. You can make this exact argument for basically structs and everything else.

Yes I am making the same argument as for structs/classes.  Structs and classes can "opt-in" and "opt-out" to exposing their fields.  Saying that all function parameter names should be exposed and coupled to the caller is like saying we shouldn't have private fields in structs and classes.

> When you use a library you are at the mercy of it's owner. I've seen some people maintain an API that just literally changed the style so basically every single line that used that API now had to be updated.

Even more reason not expose all the parameter names of all the functions in their library.  If the library owner changes any of their parameters names, they have broken compatibility with their library. This increases the opportunity for breakage dramatically.  That's the power and benefit of encapsulation, being able to change the internals without breaking your external facing API.

>
> There's already enough attributes, we shouldn't be adding more needlessly. I don't think this is a good enough reason to.

I didn't say we should add an attribute.  You're now demonstrating the "straw man fallacy" (https://en.wikipedia.org/wiki/Straw_man).