On Tuesday, 11 February 2020 at 07:04:34 UTC, Walter Bright wrote:
> On 2/10/2020 3:20 PM, Jonathan Marler wrote:
>>   I took a quick look at std.math in phobos to see what some of the current argument names are:
>> 
>> auto conj(Num)(Num z) @safe pure nothrow @nogc
>> auto abs(Num)(Num x) @nogc pure nothrow
>> real cos(real x) @safe pure nothrow @nogc { pragma(inline, true); return core.math.cos(x); }
>> auto sin(creal z) @safe pure nothrow @nogc
>> auto sin(ireal y) @safe pure nothrow @nogc
>> 
>> So we have some of this:
>> 
>> conj(z:someValue);
>> abs(x:someValue);
>> sin(y:someValue);
>> 
>> Now that parameter names are apart of the function's API, this inconsistency starts to matter
>
> It isn't inconsistent. In math, z=x+iy is normal notation, i.e. x for real numbers, y for imaginary, and z for complex.

conj and abs are using template parameters.  So if you're passing an imaginary number to conj you use "z", abs you use "x", and sin you use "y".

ireal i;
conj(z: i);
abs(x: i);
sin(y: i);

>
> Besides, I doubt there's much of any point for using named parameters for those functions.

True.  I estimate around 75% of functions in general don't benefit from named parameters.  So the question becomes, what do we do about parameter name inconsistency in these cases for the standard libraries?  If we don't think named parameters are useful for a function, will we leave them be?   If so, can we come up with a criteria we can use to determine when named parameters make sense?  I think this would help greatly in this transition to named parameters to help avoid alot of the bikeshedding I see coming when this is enabled.

I was also hoping to get some answers from the leadership to the other questions:

>> Will druntime/phobos try to come up with standard names for these situations?

For example, for math functions like the ones I mentioned, are we going to normalize on "x", "y" and "z" depending on the type?  And if it's a template that could accept any type, what name would we use in that case?  Of course, if the answer to the previous question is that we won't bother with functions that don't make sense with named parameters, then this is a bad example.  But the question still stands for functions that do make sense, do you think we should come up with a standard set of names to promote consistency accross the standard libraries, and 3rd party libraries?

Also these questions:
>> Will we try to fix these names before integrating support for named parameters?
>> If we need to change names later, what will the policy be for druntime/phobos for making parameter name changes when inconsistencies are discovered?

Also came up with another question looking through some of the external function declarations in druntime like the ones in https://github.com/dlang/druntime/blob/master/src/core/sys/windows/winbase.d

It looks like the parameter names have been stripped out for the windows functions.  Do you think we should add parameter names in those functions?  If we do want to add names, do you think we should we use the hungarian notation parameter names from windows, or no?

On Tuesday, 11 February 2020 at 15:11:18 UTC, Arine wrote:
> On Sunday, 9 February 2020 at 20:59:52 UTC, Walter Bright wrote:
>> On 2/9/2020 11:51 AM, Arine wrote:
>>> struct A {
>>>     int foo;
>>> }
>>> 
>>> struct A {
>>>      int bar; // renamed from foo
>>>      deprecated alias foo = bar;
>>> };
>>> 
>>> 
>>> False equivalency, you have many tools at your disposal to deal with this for structs.
>>
>>
>> C has it, too. Never heard a single complaint about it, either.
>>
>> https://en.cppreference.com/w/c/language/struct_initialization
>
> struct A {
>     int foo;
> };
>
> struct A {
>     union {
>         int foo;
>         int bar; // renamed to bar
>     };
> };

only since C11. anonymous unions and structs are gcc extension (or C++).

>
>
> struct A a = { .foo = 10 };
>
> False equivalency, you have some tools at your disposal to deal with this for structs in C.

On Tuesday, 11 February 2020 at 15:26:41 UTC, Paolo Invernizzi wrote:
> On Tuesday, 11 February 2020 at 15:10:35 UTC, 12345swordy wrote:
>> On Tuesday, 11 February 2020 at 15:05:48 UTC, Paolo Invernizzi wrote:
>>> On Tuesday, 11 February 2020 at 14:45:30 UTC, 12345swordy wrote:
>>>> [...]
>>>
>>> Probably I'm not able to explain myself clearly, so my fault ... let's try in this way.
>>>
>>> [...]
>>
>> Then don't rename the arguments at all if you don't want to break userspace. Same principle goes to renaming functions.
>>
>> -Alex
>
> That's exactly the point.
>
> If you don't change anything, you break anything.
>
> The more you _can_ change _without_ breaking other code is proper encapsulation, and with this DIP the amount of things that you _can't_ change is just increasing. Named arguments _enlarge_ the amount of code that you are exposing and that you _can't_ change without breaking someone else code.

If you find yourself in a situation that you end up renaming the arguments over and over again, then you got bigger issues to worry about besides named arguments.

-Alex

On Tuesday, 11 February 2020 at 15:26:42 UTC, Jonathan Marler wrote:
> On Tuesday, 11 February 2020 at 07:04:34 UTC, Walter Bright wrote:
>> On 2/10/2020 3:20 PM, Jonathan Marler wrote:
>>> Will druntime/phobos try to come up with standard names for these situations?
>
> For example, for math functions like the ones I mentioned, are we going to normalize on "x", "y" and "z" depending on the type?  And if it's a template that could accept any type, what name would we use in that case?  Of course, if the answer to the previous question is that we won't bother with functions that don't make sense with named parameters, then this is a bad example.  But the question still stands for functions that do make sense, do you think we should come up with a standard set of names to promote consistency accross the standard libraries, and 3rd party libraries?

Here's a better example: functions like move and memcpy that take source and destination arguments. Currently, move uses 'source" and "target", but memcpy uses "s2" and "s1".

On Tuesday, 11 February 2020 at 16:26:59 UTC, 12345swordy wrote:

> If you find yourself in a situation that you end up renaming the arguments over and over again, then you got bigger issues to worry about besides named arguments.
>
> -Alex

Ok, that's enough for me

On Tuesday, 11 February 2020 at 16:37:20 UTC, Paolo Invernizzi wrote:
> On Tuesday, 11 February 2020 at 16:26:59 UTC, 12345swordy wrote:
>
>> If you find yourself in a situation that you end up renaming the arguments over and over again, then you got bigger issues to worry about besides named arguments.
>>
>> -Alex
>
> Ok, that's enough for me

Look, C# has named arguments for over a decade now and you can't opt-out of it. Breakage because of the function arguments has changed rarely happens in practice, and if it does happen, it is trivial to fix.

I am going to be blunt on this, but some of the plausible scenarios being brought up is massively overblown to nonsense territory. One of the goals of Named Arguments is readability and so far no one has provided an alternative that is both useful and satisfactory to me.

Opt-in named arguments? Makes the named arguments dead on arrival.

-Alex

On 12/02/2020 6:46 AM, 12345swordy wrote:
> Opt-in named arguments? Makes the named arguments dead on arrival.

If you start with opt-in, you can make it the default later on without breaking code.

If you start with as default you cannot make it opt-in without breaking code.

To not consider an opt-in design is quite frankly over confident that other languages experiences will map 1:1 to D.

On Tuesday, 11 February 2020 at 17:58:48 UTC, rikki cattermole wrote:
> On 12/02/2020 6:46 AM, 12345swordy wrote:
>> Opt-in named arguments? Makes the named arguments dead on arrival.
>
> If you start with opt-in, you can make it the default later on without breaking code.
>
> If you start with as default you cannot make it opt-in without breaking code.
>
> To not consider an opt-in design is quite frankly over confident that other languages experiences will map 1:1 to D.

Yes, I remember and even participate in one of the dip that makes it opt-in. I consider that a terrible idea for reasons that I had already gave.

-Alex

On 2/11/2020 7:26 AM, Jonathan Marler wrote:
> True.  I estimate around 75% of functions in general don't benefit from named parameters.  So the question becomes, what do we do about parameter name inconsistency in these cases for the standard libraries?  If we don't think named parameters are useful for a function, will we leave them be?   If so, can we come up with a criteria we can use to determine when named parameters make sense?  I think this would help greatly in this transition to named parameters to help avoid alot of the bikeshedding I see coming when this is enabled.

Make some PRs to improve the consistency in advance, by all means.


> For example, for math functions like the ones I mentioned, are we going to normalize on "x", "y" and "z" depending on the type?

Sounds reasonable to me. But keep in mind that this will also result in inconsistencies. For example, points will be (x,y,z) triplets.


> And if it's a template that could accept any type, what name would we use in that case?

The most generous of the specializations.


> question still stands for functions that do make sense, do you think we should come up with a standard set of names to promote consistency accross the standard libraries, and 3rd party libraries?

I find standard names for things, like `p` for generic pointer, and `s` for generic string, and `i` for generic integer, to be valuable. But blind adherence to such will cause trouble, because it's not practical to be entirely consistent.


>>> Will we try to fix these names before integrating support for named parameters?

I wouldn't go crazy over this, but it would be nice to do it. Also, having good names for parameters is a good idea anyway.


>>> If we need to change names later, what will the policy be for druntime/phobos for making parameter name changes when inconsistencies are discovered?

Initially, we shouldn't worry about fixing it because few will be using N.P. But later, no, we shouldn't be changing them.


> It looks like the parameter names have been stripped out for the windows functions.  Do you think we should add parameter names in those functions?  If we do want to add names, do you think we should we use the hungarian notation parameter names from windows, or no?

Should use the names from the official Windows documentation. Ditto for all other APIs.

Also, there's no rush to add parameter names to APIs that don't currently have them.

On 2/11/2020 8:35 AM, Paul Backus wrote:
> Here's a better example: functions like move and memcpy that take source and destination arguments. Currently, move uses 'source" and "target", but memcpy uses "s2" and "s1".

The C99 Standard says:

  void *memcpy(void * restrict s1,
    const void * restrict s2,
    size_t n);

which is what we will slavishly use for all Standard C library functions.