DIP 1019--Named Arguments Lite--Community Review Round 2

[aliak]

On Sunday, 9 June 2019 at 19:42:19 UTC, Andrei Alexandrescu wrote:
> On 6/9/19 7:15 AM, aliak wrote:
>> On Sunday, 9 June 2019 at 07:51:18 UTC, Andrei Alexandrescu 
>> wrote:
>>> On 6/8/19 2:05 PM, Jonathan Marler wrote:
>>>> I see value in allowing a caller to omit arguments that have 
>>>> default values, but what is the value in allowing the caller 
>>>> to reorder them?
>>>
>>> Named arguments is useful mainly so one doesn't need to 
>>> remember their order in large argument lists.
>> 
>> When has anyone had a problem with unreorderable named 
>> arguments in functions with large argument lists?
>
> This is a leading question. When has anyone hadn't?

When they had never hasn'ted of course.

>
>> After using languages with unreorderable and reorderable named 
>> parameters. I only see a very mild benefit of programmer 
>> laziness for reorderable, and the larger downside of reader 
>> annoyance. I've felt no downsides of unreorderable (you 
>> generally look at the documentation, and type it in param by 
>> param, or copy paste the declaration, and if you get it wrong, 
>> the compiler tells you and you fix it).
>
> What would be those languages? The Wikipedia page 
> https://en.wikipedia.org/wiki/Named_parameter mentions:

Of the popular ones I guess those'd be objective-c and swift.

Though reordering is prevalently supported indeed.

>
> "With named parameters, it is usually possible to provide the 
> values in any arbitrary order, since the name attached to each 
> value identifies its purpose. This reduces the connascence 
> between parts of the program. A few languages use named 
> parameters but still require the parameters to be provided in a 
> specific order."

🤔 connascence... hadn't thought of that... nice.

>
> That's why the "Related Work" section is crucial. It needs to 
> make a careful account of experience in existing languages. For 
> my money, named arguments with no reordering means we're 
> wasting our time.

Not sure if it's a waste of time without reordering as apple has 
been fine without it for decades and also maintained it with the 
new language - and at least I've never heard anyone complain. 
Maybe swift just got it because obj-c had it though [0]. Couldn't 
really find any official motivational text for it.

I did find that swift had reorderable defaulted parameters [1], 
and the proposal to get rid of those basically concluded with 
"The core team prefers to encourage consistency at call sites." 
but not much else.

And then rust was talking about it as well [2], but there's no 
consensus there on whether to allow reordering or not. The 
proposal allows for it, but there's mention of the danger of it 
in one of the threads. There is however a lot of ideas and 
thoughts in that thread that would be good to address in this DIP.

[0]: 
https://www.reddit.com/r/swift/comments/5rlcnb/fixed_order_of_named_parameters/
[1]: 
https://github.com/apple/swift-evolution/blob/master/proposals/0060-defaulted-parameter-order.md
[2]: 
https://internals.rust-lang.org/t/pre-rfc-named-arguments/3831