On 8/28/2019 1:42 AM, Olivier FAURE wrote:
> To be clear, I'm not demanding that you answer what I wrote. You don't owe me anything. I'm just saying Andrei's expectations are a little unrealistic.
> 
> My feedback on DIP 1021: https://forum.dlang.org/post/imbicsoobfdugegqjozw@forum.dlang.org
> DIP draft for OB semantics: https://gist.github.com/PoignardAzur/9896ddb17b9f6d6f3d0fa5e6fe1a7088
> Lifetimes discussion: https://forum.dlang.org/thread/qssaruktegnbtsdjeyri@forum.dlang.org

Thank you!

On Wednesday, 28 August 2019 at 09:00:08 UTC, Olivier FAURE wrote:
> With all that said, I still think the way Andrei asked "well why didn't you just use Walter's version and ignore everything else?" is a little presumptuous.

Well, it's not just because Walter proposed that. It's also because his proposal is the most obvious one. There is already designated initialization syntax for arrays and structs, so having something different for parameters to a function requires, at least, some justification. Espectially considering the fact that some programming languages don't have named parameters and instead use associative arrays literals (Perl, Lua).

sub sum_abc {
    my $abc = shift;
    return $abc->{a} + $abc->{b} + $abc->{c};
}

print sum_abc({ c => 3, a => 1, b => 2}), "\n";

D doesn't have struct literal syntax (yet?), but C does:

#include <stdio.h>

typedef struct { int a, b, c; } ABC;

int sum_abc(ABC abc) {
    return abc.a + abc.b + abc.c;
}

int main(void) {
    printf("%d\n", sum_abc((ABC) { .c = 3, .a = 1, .b = 2 }));
}

That looks pretty damn close to named parameters, doesn't it... And it's plausible that one day D will get struct literals (unless it got them while I wasn't looking?) Anyway, it absolutely must be discussed in the DIP (as "Prior Work"), and it doesn't matter whether it's Walter's proposal or anyone else's.

On Tuesday, 27 August 2019 at 20:27:13 UTC, Jonathan M Davis wrote:
> On Tuesday, August 27, 2019 12:05:25 PM MDT Yuxuan Shui via Digitalmars-d wrote:
>> On Tuesday, 27 August 2019 at 17:39:44 UTC, H. S. Teoh wrote:
>> > On Tue, Aug 27, 2019 at 05:01:21PM +0000, Yuxuan Shui via
>> >
>> > Digitalmars-d wrote:
>> >> On Monday, 26 August 2019 at 21:48:42 UTC, Jonathan M Davis
>> >
>> >> wrote:
>> > [...]
>> >
>> >> > The _only_ use case IMHO where they add any real value is when you have a long parameter list where most of the parameters having default arguments.
>> >>
>> >> Disagree. Oftentimes having the name clarifies a function, so the _reader_ doesn't have to read the document to figure out what a function call does
>> >
>> > [...]
>> >
>> > That's exactly Jonathan's point.  The reader *assumes* semantics based on the names of the function and parameters.
>>
>> Well at this point you might just as well say the reader cannot *assume* semantics based on the documentation of the function either.
>
> There's a world of difference between assuming that what the documentation says is correct and assuming that you understand what a function does correctly based off of its name (and potentially the name of its parameters if named arguments are used). The name of a function should be representative of what it does and make it easier to remember what the function does after you've already read the documentation (the same would be true of parameters if named arguments are in the language), but ultimately, anyone using a function needs to read its documentation rather than assuming what it does based on its name or the name of its arguments. In worse cases, you do have to actually go read the function's source to know what it does, but that just means that the documentation was bad or nonexistent, which is of course undesirable and shouldn't happen (especially in publicly available libraries). We do all unfortunately sometimes have to deal with such situations, but regardless, it's not reasonable to assume what a function does based solely on its name, the name of its parameters, or the names of its arguments. If that's supposed to be one of the main benefits of named arguments, then I think that that's a great reason _not_ to have them.
>
> This sort of issue seems to come up at least some of the time when naming functions or types. Some people seem to think that they should be able to just think of a name and have it exist and act exactly the way they want without looking anything up. Similarly, some people tend to think that when they see a name, they should know exactly what it does based on the name and how it was used without reading the docs. None of that is reasonable IMHO. You always need to read the documentation, because it's frequently the case that a function doesn't work exactly the way you infer that it does, and unless the person who named the function thinks exactly like you do, differences in names and behaviors are bound to pop up. Ultimately, good names help people remember what stuff does (and even help them infer what things probably do before actually reading the docs), but there is no excuse for not reading the documentation (beyond it not existing, in which case, that's on the head of whoever wrote it, and you're potentially going to have to read the source code to get the information you need, which is a whole other problem).

I am not saying having argument names can completely eliminate the need to read the documents. But there are cases where the function name and parameter names so obviously indicates what the function does (e.g. createWindow(height: , width: )), if the function actually does something else, it would mean it was written terribly.

And there are also cases where you have read the document of the function, know what the function does, but cannot remember exactly what each of the parameters are for. Having the name of the parameters could help tremendously.

>
> - Jonathan M Davis

On Wednesday, 28 August 2019 at 10:40:14 UTC, Yuxuan Shui wrote:
> On Tuesday, 27 August 2019 at 20:27:13 UTC, Jonathan M Davis wrote:
>> [...]
>
> I am not saying having argument names can completely eliminate the need to read the documents. But there are cases where the function name and parameter names so obviously indicates what the function does (e.g. createWindow(height: , width: )), if the function actually does something else, it would mean it was written terribly.
>
> And there are also cases where you have read the document of the function, know what the function does, but cannot remember exactly what each of the parameters are for. Having the name of the parameters could help tremendously.
>
>> [...]

IntelliJ IDEA has a functionality to show parameter names in source code:

https://www.jetbrains.com/help/rider/Inline_Parameter_Name_Hints.html

This functionality does what the current goal of the DIP is.

Unfortunately it isn't currently implemented in the D plugin for Intellij.


Kind regards
Andre

On Wednesday, 28 August 2019 at 12:44:45 UTC, Andre Pany wrote:
>
> IntelliJ IDEA has a functionality to show parameter names in source code:
>
> https://www.jetbrains.com/help/rider/Inline_Parameter_Name_Hints.html
>
> This functionality does what the current goal of the DIP is.
>
> Unfortunately it isn't currently implemented in the D plugin for Intellij.
>
>
> Kind regards
> Andre

Many editors let you right click to an option that takes you to the declaration of the function that you use. Maybe not as supported with D as with C/C++ though.

The only reason for the named arguments are optional arguments as I see it.

On Saturday, 24 August 2019 at 16:36:51 UTC, Andrei Alexandrescu wrote:
> On 8/23/19 6:23 PM, Walter Bright wrote:
>> On 8/23/2019 3:54 AM, Mike Parker wrote:
>>> DIP 1019, "Named Arguments Lite", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter and Átila for the Formal Assessment.
>> 
>> 
>> I reiterate my previous opinion:
>> 
>> https://digitalmars.com/d/archives/digitalmars/D/DIP_1019--Named_Arguments_Lite--Community_Review_Round_2_327714.html#N327755
>
> We have two competing proposals for named arguments. Walter's alternative has been consistently ignored, though I notice Walter mentioned it more than once. That would be totally fine if the proposals were better, but it doesn't take much to figure Walter's is obviously way better, simpler, and integrates beautifully within the existing language.
>
> This entire dynamics strikes me as massively counterproductive. Why are we doing this?

I thought it was ignored because allowing mixing of positional and named arguments is terrible for readability. That is, of course, my opinion - but I didn't treat it as a serious competition until you mentioned it.

On Wednesday, 28 August 2019 at 16:23:32 UTC, IGotD- wrote:
> On Wednesday, 28 August 2019 at 12:44:45 UTC, Andre Pany wrote:
>>
>> IntelliJ IDEA has a functionality to show parameter names in source code:
>>
>> https://www.jetbrains.com/help/rider/Inline_Parameter_Name_Hints.html
>>
>> This functionality does what the current goal of the DIP is.
>>
>> Unfortunately it isn't currently implemented in the D plugin for Intellij.
>>
>>
>> Kind regards
>> Andre
>
> Many editors let you right click to an option that takes you to the declaration of the function that you use. Maybe not as supported with D as with C/C++ though.
>
> The only reason for the named arguments are optional arguments as I see it.

From your answer I am not sure you misunderstood the functionality. The source code is enhanced with the parameter names while reading the source code. You do not have to click anything.
Please see the example from the link.

Kind regards
Andre

On Wednesday, 28 August 2019 at 17:06:10 UTC, Andre Pany wrote:
>
> From your answer I am not sure you misunderstood the functionality. The source code is enhanced with the parameter names while reading the source code. You do not have to click anything.
> Please see the example from the link.
>
> Kind regards
> Andre

Yes, I've seen it. Not really my cup of tea as I think it clutters the code. However, this is an editor option that you can turn off.

Basically, we can get help from the IDE tool rather than support from the language for the purpose of clarity.

On Wednesday, 28 August 2019 at 09:37:13 UTC, nkm1 wrote:
> On Wednesday, 28 August 2019 at 09:00:08 UTC, Olivier FAURE wrote:
>> With all that said, I still think the way Andrei asked "well why didn't you just use Walter's version and ignore everything else?" is a little presumptuous.
>
> Well, it's not just because Walter proposed that. It's also because his proposal is the most obvious one. There is already designated initialization syntax for arrays and structs, so having something different for parameters to a function requires, at least, some justification. Espectially considering the fact that some programming languages don't have named parameters and instead use associative arrays literals (Perl, Lua).

I don't think it's obvious. There's trade-offs to consider, that people have spent pages debating.

On Thursday, 29 August 2019 at 21:53:36 UTC, Olivier FAURE wrote:
> On Wednesday, 28 August 2019 at 09:37:13 UTC, nkm1 wrote:
> I don't think it's obvious.

I guess it depends on whether you see functions parameters as a kind of struct (or both structs and parameters as kinds of tuple). Too me, they look almost indistinguishable. In any case, D already has certain rules for initializing structs and arrays, and the same rules _can_ be applied to parameters, so, using a variant of Occam's razor here...

> There's trade-offs to consider, that people have spent pages debating.

That's what I'm saying, no? The DIP should discuss these trade-offs (but it doesn't).
Maybe D doesn't even need named parameters. Perhaps C-style struct literals with designated initializers would be perfectly sufficient (and more useful in general, and that also would adress Jonathan Davis' concerns about rewriting Phobos). That all should be discussed in the DIP.