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.  But without actually reading the documentation, you cannot know for sure.  And I think by now we all know what happens when we make assumptions about a function that we don't actually understand.  So the point is that if you want to understand what the code actually does, you have to read the docs. Having named arguments doesn't relieve you of that need.

I can't say I 100% agree with Jonathan, but he certainly has a point that you can't avoid reading documentation at *some* point.


T

-- 
First Rule of History: History doesn't repeat itself -- historians merely repeat each other.

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.

On Tuesday, 27 August 2019 at 17:39:44 UTC, H. S. Teoh wrote:
> That's exactly Jonathan's point.  The reader *assumes* semantics based on the names of the function and parameters.  But without actually reading the documentation, you cannot know for sure.  And I think by now we all know what happens when we make assumptions about a function that we don't actually understand.  So the point is that if you want to understand what the code actually does, you have to read the docs. Having named arguments doesn't relieve you of that need.
>
> I can't say I 100% agree with Jonathan, but he certainly has a point that you can't avoid reading documentation at *some* point.
>
>
> T

Named parameters are intended for when you remember partially, but not fully, the function you are calling. Yuxan provided a good example of such situation.

Personally, I'd be unlikely to forget ordering of width and height, but if I was hunting a rendering bug and encountered `drawRect(100, 100, a[0], a[1], true)`, it's fairly likely I wouldn't remember whether the latter two parameters are absolute or relative to first two, and/or what that `true` stands for. I'd have to open the documentation, which tends to have the same effect on me as long compile times on some. Alternatively, I could open the file where `drawRect()` is defined and have Geany to hint me the parameter names, but that file could be deep in some DUB package, even slower to fire up than the docs. Assuming I wrote the call myself, parameter names would give my memory enough hint that I wouldn't have to bother with the doc.

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

- Jonathan M Davis

On 8/27/2019 8:32 AM, Olivier FAURE wrote:
> When Walter posted DIP-1021, I gave feedback with detailed examples in multiple occasions (in PR comments and the review thread), wrote a draft for a DIP that will propose an alternate implementation, and posted a type system discussion when I stalled on a problem. I have yet to see any acknowledgment of that work from Walter (atila gave some feedback, though it was fairly surface-level).

I have replied to some of it, but not all. I got called away on a crisis and haven't gotten back to it since, even my proposal on it.

BTW, when you write that you've made proposals and such, it helps a lot to include links to what you're talking about. You're far more likely get interest in it than if people have to go spelunking around wondering what specifically you're referring to.

It's the same advice I give when people say they're blocked by bugs, but never link to the bug reports (and often don't even give a hint as to what the issues are).

I try to follow my own advice: https://digitalmars.com/d/archives/digitalmars/D/DIP_1019--Named_Arguments_Lite--Final_Review_330067.html#N330105

On Monday, 26 August 2019 at 23:36:22 UTC, Jonathan M Davis wrote:
> That particular use of Flag is more valuable than many uses of it, because you actually have multiple arguments

It's exactly as valuable as single arguments. For example:

DoSomething( Multithreaded.Yes );

DoSomething( Mutlithreaded : true );

Versus:

DoSomething( true );

Or even worse:

enum bool IsMultithreaded = true;
DoSomething( IsMultithreaded );

(Two lines of code need to be understood for a single function call; and there's no guarantee that the IsMultithreaded parameter is defined next to the call site. For anyone choosing to single that one out, there's your answers.)

Did you know it's a coding standard at Insomniac - creators of Ratchet and Clank and the recent Spiderman game - to not use boolean arguments and instead create one of those yes/no enums?

I've already stated that named arguments as a language feature are not a method of enforcing programming standards on people. How you choose to approach the above problem is up to the programmer. If they want to aim for readable like my examples, great. If they want to aim for obtuse interfaces that requires understanding pages of documentation, well, that's up to them too.

Certainly, all this talk about documentation falls within the "programming standards" point I raise.

On Tuesday, August 27, 2019 9:32:03 AM MDT Olivier FAURE via Digitalmars-d wrote:
> On Saturday, 24 August 2019 at 16:36:51 UTC, Andrei Alexandrescu
>
> wrote:
> > On 8/23/19 6:23 PM, Walter Bright wrote:
> >> I reiterate my previous opinion:
> >>
> >> https://digitalmars.com/d/archives/digitalmars/D/DIP_1019--Named_Argume nts_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 kinda want to point out that neither you nor Walter have much ground to stand out when it comes to complaining about feedback being ignored.
>
> When Walter posted DIP-1021, I gave feedback with detailed examples in multiple occasions (in PR comments and the review thread), wrote a draft for a DIP that will propose an alternate implementation, and posted a type system discussion when I stalled on a problem. I have yet to see any acknowledgment of that work from Walter (atila gave some feedback, though it was fairly surface-level).
>
> I'm not saying I'm mad about that; but the way you're saying "Walter's proposal is obviously superior. Why didn't the author drop his DIP and make a new one based on Walter's idea instead?" seems a little naive of how the process tends to go.
>
> People usually don't give up on their own ideas to champion someone else's alternative. I don't, you probably don't, and Walter certainly doesn't.

A significant difference here is that Walter is one of the two people who approves DIPs. So, ignoring his feedback when writing a DIP is likely to mean that it's going to be rejected. That doesn't mean that he's right, and the proposal could very well win him over if its argumentation is improved, but ignoring what the person who's making the decision says is almost certainly going to lead to the DIP being rejected. Given that Walter has given his feedback on how he thinks named arguments should be done, I would think that anyone writing a DIP on named arguments would need to address his feedback in their DIP if they have any hope of it getting accepted.

Now, personally, I don't like the idea having named arguments in the language, so it's fine with me if everyone writing DIPs on the matter does so in a way that Walter is going to reject them, but given his position, ignoring his feedback seems like a bad idea for anyone who wants their DIP to be accepted.

- Jonathan M Davis

On Tuesday, 27 August 2019 at 16:47:24 UTC, Yuxuan Shui wrote:
> On Saturday, 24 August 2019 at 16:36:51 UTC, Andrei Alexandrescu wrote:
>> We have two competing proposals for named arguments. Walter's alternative has been consistently ignored, though I notice Walter mentioned it more than once.
>
> It _has not been_ ignored. But, it is just a feedback, not a DIP. So, due process, it is not to be treated with the same weight as a DIP.

So the DIP should definitely address the designated initializers thing (presumably in the "Prior Work" section). It should explain why named parameters must use different rules. Otherwise, the DIP is incomplete.

>> 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.
>
> Yes, so please, please write a DIP for that proposal.

The currently discussed DIP can be rejected without writing any new one...

On Tuesday, 27 August 2019 at 21:15:33 UTC, Walter Bright wrote:
> On 8/27/2019 8:32 AM, Olivier FAURE wrote:
>> When Walter posted DIP-1021, I gave feedback with detailed examples in multiple occasions (in PR comments and the review thread), wrote a draft for a DIP that will propose an alternate implementation, and posted a type system discussion when I stalled on a problem. I have yet to see any acknowledgment of that work from Walter (atila gave some feedback, though it was fairly surface-level).
>
> I have replied to some of it, but not all. I got called away on a crisis and haven't gotten back to it since, even my proposal on it.
>
> BTW, when you write that you've made proposals and such, it helps a lot to include links to what you're talking about. You're far more likely get interest in it than if people have to go spelunking around wondering what specifically you're referring to.

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

On Tuesday, 27 August 2019 at 23:08:11 UTC, Jonathan M Davis wrote:
> A significant difference here is that Walter is one of the two people who approves DIPs. So, ignoring his feedback when writing a DIP is likely to mean that it's going to be rejected.

The "Community Review Round 2" section mentions Walter's proposal as a possible superset of the current proposal.

I think the problem with this DIP isn't ignoring feedback (it has changed a lot since its initial iteration) so much as a lack of integration of that feedback into a coherent analysis.

Like, this DIP has evolved by adding and dropping features to address complaints from reviewers, but it still doesn't really justify these changes or explore the relevant trade-offs and their practical consequences.

An ideal DIP would list the possible implementations, their upsides, their downside, how to leverage the former and mitigate the latter, and why a given implementation is better for D than the others.

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.