On Sunday, 9 June 2019 at 22:49:11 UTC, aliak wrote:
> 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

Hey...rust stole my idea :)

https://internals.rust-lang.org/t/pre-rfc-named-arguments/3831

See the "API authors are in control section".  He recommends using `pub` as a parameter modifier to expose their names.

   > API authors are in control
   > Let’s start with the last point. Many proposals to add named arguments to Rust assumed that all arguments would become optional named arguments. However, this would make all the argument names part of the public API and renaming them would become a breaking change.

    > In this proposal I wish to give the ability to the API authors to choose if they want to commit to the argument names by making them part of the public API.

Funny to read the comments and see similar debate for the same thing in a completely different community :)