May 13, 2020
On 5/12/20 8:37 PM, Walter Bright wrote:
> We already have named arguments in D since the very beginning - the struct initialization syntax.
> 
> Not a single person has complained about breakage when implementers changed the names of the struct fields.

As was pointed out in the last review -- if you have structs with public member fields and you changed those names, the breakage would be more severe than just a broken initializer call:

auto s = S(1, 2, 3);

writeln(s.foo); // Error, no member foo, did you mean Foo?

It's weird to expect anyone to complain about initializer calls over actual usage.

> This is similar to:
> 
> 1. what happens if the implementer changes the types of the parameters?
> 
> 2. what happens if the implementer changes the order of the parameters?
> 
> Then user code breaks.
> 
> If anything, this feature will motivate implementers to take some care to name the parameters appropriately.

I agree, and I don't think this is going to make a huge problem for D. It would, however, be nice to provide a way to migrate parameter names like we have for functions (via deprecation attributes).

-Steve
May 13, 2020
On Wednesday, 13 May 2020 at 08:17:26 UTC, Jacob Carlborg wrote:
> On 2020-05-12 08:22, Jonathan Marler wrote:
>> A sleep function that takes milliseconds on the other hand could be helpful:
>> 
>> sleep(100);
>> sleep(msecs:100); // helpful
>
> I disagree. It's much better what we already have. The `sleep` method on `Thread` takes a duration, instead of a specific time unit. The duration is also encoded in its own type:
>

Yes I also agree that what we have in phobos is already better than this.  I was just showing an example of a theoretical sleep function that already took a integer value of milliseconds.  This was a poor example on my part.

>> Given that, here are a list of conventions:
>>
>> 2. Common generic parameter names
>> 
>> p (generic pointer argument, prefer this over ptr or pointer)
>> s (generic string argument, prefer this over str or string)
>> i (generic integer argument)
>
> I disagree. I think there are very few cases of APIs where a function expects a truly generic value. It's better to try to encode the purpose or how a value is used in the parameter name. Naming something based on what it is rarely useful, we have a much better system for that, which is the type system :). For example:
>

Good point, if we defer to the first rule, there may be no need to have a convention for generic parameters like these.

>> msecs
>> secs
>
> Same thing as the `sleep` method. Should not be a plain int, should be its own type.

When we can yes.  However the C sleep function does take an integer, in which case we can use the parameter name for clarification.

https://linux.die.net/man/3/sleep
extern "C" uint sleep(uint seconds);

sleep(2);
sleep(seconds:2);


>
> Also, we should avoiding having short, abbreviated symbol names (any kind of symbol names, not just parameter names). Although it's worse to have abbreviated names which are part of the API or show up in generated documentation. There are always exceptions, like when abbreviated name is more known and common than the actual full name. Examples are: HTTP, FTP and so on.

Yeah these are the types of things I think we should discuss, especially for the standard library before we enable this feature.

May 13, 2020
On Wednesday, 13 May 2020 at 06:11:46 UTC, Andrej Mitrovic wrote:
> [snip]
>
> I see people mentioning wrapper overloads to enable deprecation of old parameter names. But why not just support this in code?
>
> Something like:
>
> ```D
> void foo (@deprecated("x_val") int x, @deprecated("y_val") int y)
> {
> }
> ```
>
> And then the compiler emits warnings if you use `foo(x_val : 10, y_val : 20)`.

So there wouldn't be a warning if they call foo(10, 20)?

That would mean the user couldn't provide an alternate `void foo(int x_new_name, int y_new_name) {}` until the deprecation period ends. If you make it so that a function with deprecated names can only be called with the old names specifically, then this would free the implementers up to write a separate function with new names. Any call like foo(10, 20) wouldn't change if they supply the new function, but a call like foo(x_val: 10, y_val: 20) would get a deprecation message.

Another way to think of it would be that functions without deprecated parameter names have higher priority in the overload set than ones with deprecated names.

I think this would resolve my concern with deprecations, if Walter goes for it.
May 13, 2020
On Wednesday, 13 May 2020 at 06:11:46 UTC, Andrej Mitrovic wrote:
> On Monday, 11 May 2020 at 11:37:07 UTC, Mike Parker wrote:
>> This is the discussion thread for the Final Review of DIP 1030, "Named Arguments":
>>
>> https://github.com/dlang/DIPs/blob/7d114c93edb02d8fc4b05f0716bdb6057905fec2/DIPs/DIP1030.md
>
> I see people mentioning wrapper overloads to enable deprecation of old parameter names. But why not just support this in code?
>
> Something like:
>
> ```D
> void foo (@deprecated("x_val") int x, @deprecated("y_val") int y)
> {
> }
> ```
>
> And then the compiler emits warnings if you use `foo(x_val : 10, y_val : 20)`.

What happens if
a) you change the argument names twice
b) you re-order the argument names
c) you want to change the name and type

tl;dr: I believe it would be more general-purpose if the compiler would allow this:

```
void foo(int x, int y) { ... }

@deprecated extern(D, argNames)
void foo(int xVal, int yVal) { ... }
```

And then the compiler prefers non-deprecated overload if it's not explicitly requested.

Though that would require including the argument names into the function mangling of the deprecated which is requested here with the fictional extern (D, argNames).
May 13, 2020
On 5/13/2020 12:55 AM, Jacob Carlborg wrote:
> Regarding renaming parameters will break the API. Swift supports giving a different name which are used locally:
> 
> func copy(_ source: String, to destination: String)
> 
> Should be called like this:
> 
> copy("foo", to: "bar")
> 
> `_` indicates that the argument can not be named when calling the function.

In D, we do:

   void copy(string, string destination);
May 13, 2020
On 5/13/20 3:30 PM, Walter Bright wrote:
> On 5/13/2020 12:55 AM, Jacob Carlborg wrote:
>> Regarding renaming parameters will break the API. Swift supports giving a different name which are used locally:
>>
>> func copy(_ source: String, to destination: String)
>>
>> Should be called like this:
>>
>> copy("foo", to: "bar")
>>
>> `_` indicates that the argument can not be named when calling the function.
> 
> In D, we do:
> 
>     void copy(string, string destination);

And how does the implementation of copy use that first parameter?

-Steve
May 13, 2020
On Wednesday, 13 May 2020 at 19:31:24 UTC, Steven Schveighoffer wrote:
> On 5/13/20 3:30 PM, Walter Bright wrote:
>> On 5/13/2020 12:55 AM, Jacob Carlborg wrote:
>>> Regarding renaming parameters will break the API. Swift supports giving a different name which are used locally:
>>>
>>> func copy(_ source: String, to destination: String)
>>>
>>> Should be called like this:
>>>
>>> copy("foo", to: "bar")
>>>
>>> `_` indicates that the argument can not be named when calling the function.
>> 
>> In D, we do:
>> 
>>     void copy(string, string destination);
>
> And how does the implementation of copy use that first parameter?
>
> -Steve

I found a way:

void copy(string, string destination)
{
    alias source = _param_0;
}

I didn't realize you could do this till now but this allows functions to "opt-out" of using named parameters.  We may want to consider using this pattern throughout phobos/druntime when we want want to prevent parameter names from being apart of the API.

May 13, 2020
On Wednesday, 13 May 2020 at 19:44:32 UTC, Jonathan Marler wrote:
> I found a way:
>
> void copy(string, string destination)
> {
>     alias source = _param_0;
> }
>
> I didn't realize you could do this till now but this allows functions to "opt-out" of using named parameters.  We may want to consider using this pattern throughout phobos/druntime when we want want to prevent parameter names from being apart of the API.

Makes the documentation worse though.
May 13, 2020
On Wednesday, 13 May 2020 at 19:48:58 UTC, Panke wrote:
> On Wednesday, 13 May 2020 at 19:44:32 UTC, Jonathan Marler wrote:
>> I found a way:
>>
>> void copy(string, string destination)
>> {
>>     alias source = _param_0;
>> }
>>
>> I didn't realize you could do this till now but this allows functions to "opt-out" of using named parameters.  We may want to consider using this pattern throughout phobos/druntime when we want want to prevent parameter names from being apart of the API.
>
> Makes the documentation worse though.

If it makes the documentation worse then it means the parameter names were helpful to the API, in which case you wouldn't do this.  The "copy" function isn't a good example because the "source" and "destination" parameter names are actually helpful to include.

May 13, 2020
On Wednesday, 13 May 2020 at 19:44:32 UTC, Jonathan Marler wrote:
> On Wednesday, 13 May 2020 at 19:31:24 UTC, Steven Schveighoffer wrote:
>> On 5/13/20 3:30 PM, Walter Bright wrote:
>>> On 5/13/2020 12:55 AM, Jacob Carlborg wrote:
>>>> Regarding renaming parameters will break the API. Swift supports giving a different name which are used locally:
>>>>
>>>> func copy(_ source: String, to destination: String)
>>>>
>>>> Should be called like this:
>>>>
>>>> copy("foo", to: "bar")
>>>>
>>>> `_` indicates that the argument can not be named when calling the function.
>>> 
>>> In D, we do:
>>> 
>>>     void copy(string, string destination);
>>
>> And how does the implementation of copy use that first parameter?
>>
>> -Steve
>
> I found a way:
>
> void copy(string, string destination)
> {
>     alias source = _param_0;
> }
>
> I didn't realize you could do this till now but this allows functions to "opt-out" of using named parameters.  We may want to consider using this pattern throughout phobos/druntime when we want want to prevent parameter names from being apart of the API.

I've created a PR to use this pattern in some of the functions in std.math: https://github.com/dlang/phobos/pull/7480

Let's see what the community thinks about this pattern and if it should be adopted by druntime/phobos in anticipation of enabling named parameters.