On Thursday, 6 June 2019 at 22:26:57 UTC, Adam D. Ruppe wrote:
> 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?

Seems like a silly question doesn't it?  Have you ever changed the name of an argument in a library?

Have you ever changed the name of private field in a struct/class?  What you're saying is that functions should not have any privacy/encapsulation when it comes to parameters names.  Do you also think structs and classes should not have the private modifier?

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

Again...do you also apply this same argument to having private fields in structs/classes?

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

So in that case, you would make the parameter "public" so you could expose a change in semantics.  I'm not saying we shouldn't have named arguments, I'm saying it should be "opt-in".

On Thursday, 6 June 2019 at 22:38:53 UTC, Jonathan Marler wrote:
> On Thursday, 6 June 2019 at 22:26:57 UTC, Adam D. Ruppe wrote:
>> 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?
>
> Seems like a silly question doesn't it?  Have you ever changed the name of an argument in a library?
>
> Have you ever changed the name of private field in a struct/class?  What you're saying is that functions should not have any privacy/encapsulation when it comes to parameters names.
>  Do you also think structs and classes should not have the private modifier?
>
>>
>> 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.
>
> Again...do you also apply this same argument to having private fields in structs/classes?
>
>>
>> Though if the name changes, it might indicate a change in meaning of the param too, so maybe breakage is a good thing.
>
> So in that case, you would make the parameter "public" so you could expose a change in semantics.  I'm not saying we shouldn't have named arguments, I'm saying it should be "opt-in".

I do see some weaknesses with the "opt-in" approach.

The first one being that once a library decides to "opt-in", depending on how it's done, it may break that library from being compile-able by older compilers.

Also if named parameters were more useful, say around 50% of all functions, I would probably lean towards saying that we could sacrifice encapsulation and just have everything opt-in by default.  But because I think it will be needed more rarely, "opt-in" seems to make sense to me to preserve encapsulation of parameter names.

On Thursday, 6 June 2019 at 22:35:31 UTC, Jonathan Marler wrote:
> 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.

That doesn't make any sense. To make a function parameter "private" that would mean the user wouldn't be able to pass in a value to it. They are already public, they just need a name now.

Why aren't you proposing this instead then ?

   void foo(private int a, public int b) { }

Cause it doesn't make sense, not one wants to deal with that address complexity because it provides zero benefit. The only benefit you get from having names be optional is that library maintainers can screw over their user base if they want to use the feature or not. This does not solve anything by making it optional. Every issue you can have with it not being optional is already a problem today with existing features, and there's no solution to it a side from governing people that use D.

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

That power is entirely depending on the person writing it. If the maintainer wants to keep backwards compatibility with named arguments it is very easy to do so. This is NOT encapsulation, you can still access parameters. Making it optional won't make maintainers be good maintainers, it will just make the users suffer and avoid the feature for its uselessness.

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

What the, this isn't even the main argument and your pulling that card? Come on now. I would be interested in hearing how you will mark one function as optional and another as not optional though. Someone suggested @named, I have yet to hear anything better from you.

On Thursday, 6 June 2019 at 23:08:56 UTC, Exil wrote:
> On Thursday, 6 June 2019 at 22:35:31 UTC, Jonathan Marler wrote:
>> 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.
>
> That doesn't make any sense. To make a function parameter "private" that would mean the user wouldn't be able to pass in a value to it.

That's not the meaning I proposed.  I proposed that public exposes the "name" of the function parameter.  You're "straw manning" again, please look that one up.  Understand what I'm saying before you respond.

> Cause it doesn't make sense, not one wants to deal with that address complexity because it provides zero benefit.

Encapsulation = Zero Benefit?

Well I can see we're not going to agree here :)

> The only benefit you get from having names be optional is that library maintainers can screw over their user base if they want to use the feature or not.

Again, the benefit is Encapsulation.

>>> 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.
>
> That power is entirely depending on the person writing it. If the maintainer wants to keep backwards compatibility with named arguments it is very easy to do so. This is NOT encapsulation, you can still access parameters. Making it optional won't make maintainers be good maintainers, it will just make the users suffer and avoid the feature for its uselessness.
>

You seem to be confusing what I said.  I didn't say the parameters are encapsulated...that doesn't make any sense.  I'm talking about encapsulating the 'names' of the parameters.  I think once you understand the distinction you'll see you're response here doesn't make much sense.

>>> 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).
>
> What the, this isn't even the main argument and your pulling that card? Come on now. I would be interested in hearing how you will mark one function as optional and another as not optional though. Someone suggested @named, I have yet to hear anything better from you.


You just need a way to distinguish named from unnamed.  Opt-in and Opt out.  You could do so by putting all your named arguments in a struct and supporting some caller syntax to expand arguments into that struct.  You could use tuples, you could use a special type wrapper. And yes, you could use an attribute like "public", but you don't have too is the point.

Keep in mind that I'm not trying to say that you don't have any points here.  You are correct that having to opt-in means you have to depend on your libraries to opt-in to using named arguments before you can use them. That's a valid point.

I'm just weighing the pros and cons here.  I see a big con to enabling this by default for every function in D.  I see a small benefit from the feature altogether, as it's only useful for a small percentage of functions.  We can argue over how big/small those factors are, but I hope we agree that they are factors and that encapsulation matters and is important.  We can argue over the value of encapsulating parameter names, but you shouldn't dismiss it altogether.  A good scientist weighs all the factors without any bias, whether or not they agree with his/her initial hypothesis.  Listen to what others are saying and consider it.  We're not at war trying to "beat" each other, we're on the same team trying to make D better for everyone.

On 06.06.19 22:04, Walter Bright wrote:
> I'll reiterate what I wrote for DIP1020 https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html#N325627 
> 
> 
> ---
> 
> Here's a much simpler proposal, based on the recognition that D already has
> named parameters:
> ...

I think this is indeed the way to go, but ideally, named arguments would become first-class citizens. E.g., this should work: [1]

void foo(int x,string y){}

void main(){
    auto t=tuple(y: "123", x: 2);
    foo(t.expand); // ok
}

I.e., named arguments should be allowed in alias sequences.

This is important e.g. for forwarding applications.



[1] With the tuple DIP, it would become just

void main(){
    auto t=(y: "123", x: 2);
    foo(t);
}

On 06.06.19 22:04, Walter Bright wrote:
> 
> 
> 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?

Lexical order of the arguments. Evaluating in order of source code is a good policy. Also, this is the only sensible choice considering that named alias sequences should be an independent concept.

On Thursday, 6 June 2019 at 22:19:46 UTC, Jonathan Marler wrote:
> You missed the point.

No, you are the one who is missing the point here. Point being is that fix breakage cause by name change is quick, simple and easy. The tools are advance enough for quick fixes.

>  There are not that many functions that will benefit from using named parameters.

Says who!? You? Readability matters a lot to me. I hate C++, because it is so bad at readability.

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

Sorry I don't believe that it is a "high cost". Tools are quite good enough to compensate the change.

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

No, they are not the same thing! Encapsulation involves information hiding, and confidentiality. It makes no sense to hide the names of the function arguments when exposed to the public.


I am not going to repeat of what I said months ago regarding this. I have said my arguments on why making it opt-in is a terrible idea. Not going to rehash it again.

Alex

On 07.06.19 00:38, Jonathan Marler wrote:
>>
>> 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.
> 
> Again...do you also apply this same argument to having private fields in structs/classes?

This analogy has no merit. Why would function arguments need a notion of encapsulation? They are part of the interface by definition.

On Thursday, 6 June 2019 at 23:36:11 UTC, Jonathan Marler wrote:
> On Thursday, 6 June 2019 at 23:08:56 UTC, Exil wrote:
>> On Thursday, 6 June 2019 at 22:35:31 UTC, Jonathan Marler wrote:
>>> 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.
>>
>> That doesn't make any sense. To make a function parameter "private" that would mean the user wouldn't be able to pass in a value to it.
>
> That's not the meaning I proposed.  I proposed that public exposes the "name" of the function parameter.  You're "straw manning" again, please look that one up.  Understand what I'm saying before you respond.

It's what private currently means. You are misunderstanding what I am saying and throwing around strawman like it applies. Encapsulation/private/public do not relate at all to what you are suggesting.

>> Cause it doesn't make sense, not one wants to deal with that address complexity because it provides zero benefit.
>
> Encapsulation = Zero Benefit?
>
> Well I can see we're not going to agree here :)

This is not encapsulation. You are conflating the two. Talk about strawman...

>> The only benefit you get from having names be optional is that library maintainers can screw over their user base if they want to use the feature or not.
>
> Again, the benefit is Encapsulation.

It is not encapsulation.

>>>> 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.
>>
>> That power is entirely depending on the person writing it. If the maintainer wants to keep backwards compatibility with named arguments it is very easy to do so. This is NOT encapsulation, you can still access parameters. Making it optional won't make maintainers be good maintainers, it will just make the users suffer and avoid the feature for its uselessness.
>>
>
> You seem to be confusing what I said.  I didn't say the parameters are encapsulated...that doesn't make any sense.  I'm talking about encapsulating the 'names' of the parameters.  I think once you understand the distinction you'll see you're response here doesn't make much sense.

And you are going on and on about encapsulation... I understand what you are saying. That is not encapsulation, and what you are proposing is not useful. It prevents a useful feature from being used, if API maintainers don't want to maintain it, then they don't have to. Just like everything else. But then no one will use their API, and/or people will complain and it will be fixed.

>>>> 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).
>>
>> What the, this isn't even the main argument and your pulling that card? Come on now. I would be interested in hearing how you will mark one function as optional and another as not optional though. Someone suggested @named, I have yet to hear anything better from you.
>
>
> You just need a way to distinguish named from unnamed.  Opt-in and Opt out.  You could do so by putting all your named arguments in a struct and supporting some caller syntax to expand arguments into that struct.  You could use tuples, you could use a special type wrapper. And yes, you could use an attribute like "public", but you don't have too is the point.

Those all sound like terrible ideas. I need an extra struct to be able to use named and unnamed functions? So now named parameters dictate the design? I can only imagine the additional problems this would add. A special type wrapper might be worse than an extra attribute.

> I'm just weighing the pros and cons here.  I see a big con to enabling this by default for every function in D.  I see a small benefit from the feature altogether, as it's only useful for a small percentage of functions.

It doesn't matter what percentage. That's the thing, you might say this section of is more important and should use named parameters. But I disagree, and I think this other section should have named parameters. But you are the library maintainer, so you make your choice and you chose to ignore mine. Now I use your library and I am restricted to which functions I can use a language feature on. I can't use the language feature where I want to because of the maintainer's opinion.

struct A {
private:
    int a;
}

 A a;
 a.a = 10; // error can't do it

void foo( int value );

foo( value: 10 ); // error not defined to use named parameters
foo( 10 ); // functionally the same

The whole idea of "encapsulating" the variable name is completely bonkers to me. It's a feature that is mislabeling something as encapsulation and is trying to shoehorn it is with statements on the basis that "encapsulation" can't be bad. It is when you don't know what it is or why it is useful.

On 07.06.19 01:36, Jonathan Marler wrote:
> On Thursday, 6 June 2019 at 23:08:56 UTC, Exil wrote:
>> On Thursday, 6 June 2019 at 22:35:31 UTC, Jonathan Marler wrote:
>>> 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.
>>
>> That doesn't make any sense. To make a function parameter "private" that would mean the user wouldn't be able to pass in a value to it.
> 
> That's not the meaning I proposed.  I proposed that public exposes the "name" of the function parameter.  You're "straw manning" again,

No, he's just not arguing against the aspect of your idea that you think he is. You are the one setting up the straw man.

> please look that one up.  Understand what I'm saying before you respond.
> ...

That's a pretty hard constraint to satisfy, considering that you are not making any sense.

>> Cause it doesn't make sense, not one wants to deal with that address complexity because it provides zero benefit.
> 
> Encapsulation = Zero Benefit?
> 
> Well I can see we're not going to agree here :)
> ...

His point was that hiding argument names is not "encapsulation". You are arguing against a straw man. Note that mentioning fallacies by name is actually rarely useful.

>> The only benefit you get from having names be optional is that library maintainers can screw over their user base if they want to use the feature or not.
> 
> Again, the benefit is Encapsulation.

Well, let's look at the facts:

- Parameter names are already exposed, and changing parameter names can already break third-party code:
https://dlang.org/phobos/std_traits.html#ParameterIdentifierTuple

No "encapsulation" for you. (Whatever that's supposed to mean.)

- It is possible to not name parameters (an alternative way is to use *.di files):

import std.traits;
int add(int, int){
    return _param_0+_param_1;
}
void main(){
    assert(add(1,2)==3);
}

I guess that's what you would call "encapsulation".

I.e., if you want to not expose any parameter names, you have the means to do so. Let's call those two ways to declare parameters public and private. What named arguments allow you to do is to actually refer to the public parameters by name.

If we had structs with public and private fields, there was no field access (e.f) syntax and you could only access public fields by index, would you also argue that this is a good thing, even if there was already a __trait to get the index of a field from its name and vice-versa?