DIP 1030--Named Arguments--Community Review Round 1 Discussion

[aliak]

On Wednesday, 12 February 2020 at 05:03:49 UTC, Jonathan M Davis 
wrote:
> On Friday, February 7, 2020 8:57:56 PM MST Walter Bright via 
> Digitalmars-d wrote:
>> On 2/6/2020 7:33 PM, Jonathan M Davis wrote:
>> > Well, I'll say again that I don't like the idea of having 
>> > named arguments in the language, because it makes the 
>> > parameter names part of the API, resulting in yet more 
>> > bikeshedding and yet another thing that can't be changed 
>> > without breaking existing code. Once in a while, named 
>> > arguments may be useful, 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.
>> >
>> > Unfortunately, since it's Walter who created the DIP, and a 
>> > number of people do like the idea of named arguments, I 
>> > expect that some form of this will make it in, but I still 
>> > think that it's a bad idea.
>>
>> I appreciate your thoughts on this. But I like the feature 
>> even if all it does is make the "Flag" template obsolete:
>>
>>    https://dlang.org/library/std/typecons/flag.html
>>
>> So instead of:
>>
>>    foo(Yes.caseSensitive)
>>
>> we'd write:
>>
>>    foo(caseSensitive : true)
>>
>> There's no overhead or cognitive load of an extra type, and it 
>> doesn't look stupid.
>
> That is an upside to it, though I don't think that it's worth 
> having to deal with named arguments in general just get rid of 
> Flag. I confess though that I've always thought that Flag was 
> an unnecessary complication and have only used it because 
> people have been insisting that it's best practice. I never use 
> it in code that isn't in a library that I'm writing for other 
> people to use. If you're familiar with the function, then a 
> naked bool is enough to understand what the function call is 
> doing and no sort of argument name at the call site is 
> necessary. If you aren't familiar with the function, then you 
> should be reading its documentation anyway instead of assuming 
> that you understand what it does based simply on what it's 
> called or what the names of its arguments are. And in that 
> sense, named arguments seem to me like a further excuse to try 
> to claim that you don't need to actually read the documentation 
> to understand what functions do, which ultimately leads to 
> shooting yourself in the foot when you make an assumption that 
> doesn't match the assumptions that the function's author made.

Named arguments is the difference between spending 1 second 
looking at this:

makeWindow(x: 67, y: 98, width: 100, height: 100)

Or taking about 1 to 5 minutes depending on how easy 
documentation is to find, and how bored you are to figure out 
what this is doing:

makeWindow(67, 98, 100, 100)

The 1 to 5 minutes is guesstimate work. But there's a lot of 
research out there about human task behavior. E.g. you have about 
2-3 minutes of someone's attention before you switch tasks. It 
can take anywhere from a minute to 20 to get back to what you 
were doing after a context switch. Looking up and searching for 
documentation unnecessarily is most certainly a context switch. 
Add the fact that many libraries do not have documentation or 
poor documentation, that means browsing the source code. Throw in 
attention spans and anything you can do to make code 
readable/reviewable is a huge win to productivity.

Unless you're a lone programmer working on your own project 
consistently this doesn't apply. But even then if you switch 
between projects it does, because there's no way you're remember 
what every bool or int parameter does.

Coding in the professional world is mostly social. The languages 
that make it more social and help that aspect will win the long 
game.

>
> - Jonathan M Davis