On Wednesday, 19 February 2020 at 19:57:06 UTC, 12345swordy wrote:
> On Wednesday, 19 February 2020 at 19:34:53 UTC, bachmeier wrote:
>> On Wednesday, 19 February 2020 at 19:13:01 UTC, Jonathan M Davis wrote:
>>> [...]
>>
>> I agree. I know there are complaints about being required to use a particular tool to use a language, but this particular argument for named parameters uses a language change - one with big side effects - to do something that should be done by an IDE. The nice thing about proper editor support is that it continues to work exactly as expected even if you do change the parameter names in the library.
>
> What editor are you specifically talking about here and how should it be done? Generating comments like this?
>
> go(\*a*\ 1);
>
> Alex

E.g. CLion does it. In renders the parameter names at the call site without changing the code at all (it does not insert comments). It is a very useful feature. Granted, if that support was readily available for D than the argument for named parameters would be weaker.

On Wednesday, 19 February 2020 at 20:04:56 UTC, Panke wrote:
> On Wednesday, 19 February 2020 at 19:57:06 UTC, 12345swordy wrote:
>> On Wednesday, 19 February 2020 at 19:34:53 UTC, bachmeier wrote:
>>> [...]
>>
>> What editor are you specifically talking about here and how should it be done? Generating comments like this?
>>
>> go(\*a*\ 1);
>>
>> Alex
>
> E.g. CLion does it. In renders the parameter names at the call site without changing the code at all (it does not insert comments). It is a very useful feature. Granted, if that support was readily available for D than the argument for named parameters would be weaker.

Isn't that mainly due to cpp having header files?

-Alex

On Wednesday, 19 February 2020 at 20:09:25 UTC, 12345swordy wrote:
> On Wednesday, 19 February 2020 at 20:04:56 UTC, Panke wrote:
>> On Wednesday, 19 February 2020 at 19:57:06 UTC, 12345swordy wrote:
>>> On Wednesday, 19 February 2020 at 19:34:53 UTC, bachmeier wrote:
>>>> [...]
>>>
>>> What editor are you specifically talking about here and how should it be done? Generating comments like this?
>>>
>>> go(\*a*\ 1);
>>>
>>> Alex
>>
>> E.g. CLion does it. In renders the parameter names at the call site without changing the code at all (it does not insert comments). It is a very useful feature. Granted, if that support was readily available for D than the argument for named parameters would be weaker.
>
> Isn't that mainly due to cpp having header files?
>
> -Alex

Jetbrains C# IDE also has the feature where the IDE shows the parameter names, rather than the names being embedded in the code. So not really limited to header files.

On Wednesday, 19 February 2020 at 20:09:25 UTC, 12345swordy wrote:
> Isn't that mainly due to cpp having header files?
>
> -Alex

It displays the argument names where the function is used, so I see no connection to header files.

On Monday, 10 February 2020 at 21:54:53 UTC, jmh530 wrote:
> On Monday, 10 February 2020 at 21:41:02 UTC, Manu wrote:
>> [...]
>
> I was leaning towards favoring this DIP, as I frequently use named arguments in R and like the flexibility they offer in some cases. However, I came across two functions, written in python, at work. One takes a parameter and the other takes a slightly different parameter name. No good reason why these two do not use the same parameter names. They should be the same.

<snip>

> However, python has named arguments for everything,

Nope: https://www.python.org/dev/peps/pep-0570/

On Thursday, 20 February 2020 at 11:00:16 UTC, Atila Neves wrote:
> [snip]
>
> Nope: https://www.python.org/dev/peps/pep-0570/

1) Pep 570 is opt-in*. It gives you a bit more control so you can have positional-only and key-word only arguments. However, if you do not opt-in, then python still has a mixed of positional and named arguments for everything. See the standard_arg function in function examples:

https://www.python.org/dev/peps/pep-0570/#function-examples

In particular, I was thinking of situation where you have two functions

def foo(arg1, arg2):
def bar(arg1 other1):

The following code is completely valid, both pre and post pep 570

foo(a, b)
bar(a, b)
foo(arg2=b, arg1=a)
bar(other1=b, arg1=a)

In my case, I was noticing that other1 is a lot like arg2, so you want to change other1's name to arg2. However, that will break the last line. Under pep 570, you could have instead written

def foo(arg1, arg2, /):
def bar(arg1 other1, /):

and it won't break when you re-name it, but then you can't use the last two lines. Alternately, if try to use something like

def foo(*, arg1, arg2):
def bar(*, arg1 other1):

then the first two lines calling foo and bar won't work. So even under pep 570, you would still be breaking code to re-name it. The problem comes from the standard method of mixing positional or keyword arguments.

2) Referring again to the pep 570 function examples, they have

def combined_example(pos_only, /, mixed, *, kwd_only):

where mixed (called standard in their example) is the mix of positional and keyword  arguments. If D were to move in this direction, then we would have a similar function like

void combined_example(Type1 pos_only, /, Type2 mixed, *, Type3 kwd_only)

The only thing I would change is that pos_only should remain the default. So that would imply that the python function examples would instead be something like below in D.

void standard_arg(Type1 pos_only)
void mixed_arg(/, Type2 mixed)
void kwd_only_arg(*, Type3 kwd_only)

This would make named arguments opt-in and reduce the risk of people causing code breakage by changing APIs. One could start with just the mixed and consider adding the keyword only approach in the future if people want/need it.


* That pep only was implemented in Python 3.8, which only came out in October of last year, I think I'm using 3.7 at work...so admittedly less familiar with it.

On Thursday, 20 February 2020 at 11:59:13 UTC, jmh530 wrote:
> On Thursday, 20 February 2020 at 11:00:16 UTC, Atila Neves wrote:
>> [snip]
>>
>> Nope: https://www.python.org/dev/peps/pep-0570/
>
> 1) Pep 570 is opt-in*. It gives you a bit more control so you can have positional-only and key-word only arguments. However, if you do not opt-in, then python still has a mixed of positional and named arguments for everything. See the standard_arg function in function examples:

That's the exact reason why they proposed 570: having named argument is not alway a win.

On Wednesday, 19 February 2020 at 19:13:01 UTC, Jonathan M Davis wrote:
> On Wednesday, February 19, 2020 8:31:00 AM MST Yuxuan Shui via Digitalmars-d wrote:
>> On Friday, 7 February 2020 at 03:33:26 UTC, Jonathan M Davis
>>
>> wrote:
>> > but for the most part, they're useful because a function has way too many parameters, in which case, the function should have been designed differently.
>>
>> Named parameters are not just for when there are too many parameters.
>>
>> Easy example:
>>
>>      dup2(a, b);
>>
>> vs
>>
>>      dup2(src: a, dst: b);
>
> Named arguments are completely unnecessary in such a situation. The list of arguments is short enough that it's trivial to know which is which and what they're for.

This is off the mark. Named arguments are very useful even in this case (maybe *especially* in this case, when you have to rely on the convention that src always comes first and dst always comes second). I've been using Groovy a lot at work lately, which has support for named arguments (and interpolated strings, by the way), and it allows for writing some very clear and readable code.

On Thursday, 20 February 2020 at 14:49:42 UTC, Paolo Invernizzi wrote:
> On Thursday, 20 February 2020 at 11:59:13 UTC, jmh530 wrote:
>> On Thursday, 20 February 2020 at 11:00:16 UTC, Atila Neves wrote:
>>> [snip]
>>>
>>> Nope: https://www.python.org/dev/peps/pep-0570/
>>
>> 1) Pep 570 is opt-in*. It gives you a bit more control so you can have positional-only and key-word only arguments. However, if you do not opt-in, then python still has a mixed of positional and named arguments for everything. See the standard_arg function in function examples:
>
> That's the exact reason why they proposed 570: having named argument is not alway a win.

I don't think nor do I expect that people would used named arguments all the time when using another persons code.

-Alex

On Thursday, 20 February 2020 at 15:34:31 UTC, 12345swordy wrote:
> On Thursday, 20 February 2020 at 14:49:42 UTC, Paolo Invernizzi wrote:
>> On Thursday, 20 February 2020 at 11:59:13 UTC, jmh530 wrote:
>>> On Thursday, 20 February 2020 at 11:00:16 UTC, Atila Neves wrote:
>>>> [snip]
>>>>
>>>> Nope: https://www.python.org/dev/peps/pep-0570/
>>>
>>> 1) Pep 570 is opt-in*. It gives you a bit more control so you can have positional-only and key-word only arguments. However, if you do not opt-in, then python still has a mixed of positional and named arguments for everything. See the standard_arg function in function examples:
>>
>> That's the exact reason why they proposed 570: having named argument is not alway a win.
>
> I don't think nor do I expect that people would used named arguments all the time when using another persons code.
>
> -Alex

*Unless it is mandate by the language obviously*

-Alex