June 09, 2019
On Sunday, 9 June 2019 at 07:55:50 UTC, Andrei Alexandrescu wrote:
> On 6/8/19 3:58 PM, Yuxuan Shui wrote:
>> 
>> Reordering is definitely a very important feature. However, this proposal is not going to be the last DIP about named parameters, as is stressed in the proposal itself.
>> 
>> Generally, I think incremental improvements should be allowed.
>
> Sadly my vast and mostly unsuccessful experience with programming language design is that such is not to be done incrementally. Never. I will oppose a DIP that argues its utility by means of possible future DIPs. (For measure, don't forget I do not hold decision power any longer.)

Care to share your experience? Statements like this will be much more helpful when paired with the process of how they are reached.


June 09, 2019
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

June 10, 2019
On 09.06.19 23:01, Jonathan Marler wrote:
> On Sunday, 9 June 2019 at 19:43:54 UTC, Andrei Alexandrescu wrote:
>> On 6/9/19 7:27 AM, aliak wrote:
>>> With reorderable, as Walter pointed out, what't the order (parameter-wise or argument-wise).
>>
>> Lexical order of course.
> 
> Lexical order of the definition or the caller?
> ...

Lexical order means lexical order. It's the order in which the arguments are written in the source code.

> So far we have 1 for the caller and 1 for the definition.

This is simply not true. Count again.

> Both seem to think their choice is the obviously correct one :)
> ...

One of those two is wrong, and is actually a minority.

>    > Patrick Schluter:
>    > They are in the order of declaration of the function...There's no reason to evaluate it any other order ...
> ...

Clearly there are multiple reasons to do that.

>    > Paul Backus:
>    > Personally, I think the obviously-correct choice is to evaluate them in lexical order (i.e., order of the call).
> 

Yes.
June 09, 2019
On 6/9/2019 12:42 PM, Andrei Alexandrescu wrote:
> For my money, named arguments with no reordering means we're wasting our time.

I agree. We'd just have to add it in later. I don't want to have to constantly explain why reordering isn't supported. Might as well do it right the first time, especially since it is simple and D already does this for field initializers.
June 09, 2019
On 6/9/2019 4:54 AM, Atila Neves wrote:
> I've lost count of how many times I've shaken my fist at the sky when trying to change the working directory when calling std.process.execute.


https://i.kym-cdn.com/entries/icons/original/000/019/304/old.jpg
June 10, 2019
On 6/9/19 5:01 PM, Jonathan Marler wrote:
> On Sunday, 9 June 2019 at 19:43:54 UTC, Andrei Alexandrescu wrote:
>> On 6/9/19 7:27 AM, aliak wrote:
>>> With reorderable, as Walter pointed out, what't the order (parameter-wise or argument-wise).
>>
>> Lexical order of course.
> 
> Lexical order of the definition or the caller?

Order of the call. One doesn't need to examine the function declaration to figure out the order of evaluation at call site.

June 10, 2019
On Wednesday, 5 June 2019 at 13:03:26 UTC, Mike Parker wrote:
> This is the feedback thread for the second round of Community Review for DIP 1019, "Named Arguments Lite":
>
> https://github.com/dlang/DIPs/blob/9c9cc39246de4c449fe1e6cb6b27f7e426ff1eb9/DIPs/DIP1019.md
>

I've just discovered that I had locally committed the edits I made to this DIP but never pushed to them to the repository. That's why it was marked as "Post-Community 1" and not "Community Review Round 2".

You've all been reviewing the correct content--the DIP author's revisions--just without my copy edits. So all of the feedback so far is perfectly valid. I'm only posting for completeness. The edited version is here:

https://github.com/dlang/DIPs/blob/e3037dd967b5672e48d0f09b85f082540155d83b/DIPs/DIP1019.md


June 10, 2019
On Sunday, 9 June 2019 at 21:01:35 UTC, Jonathan Marler wrote:
> On Sunday, 9 June 2019 at 19:43:54 UTC, Andrei Alexandrescu wrote:
>> On 6/9/19 7:27 AM, aliak wrote:
>>> With reorderable, as Walter pointed out, what't the order (parameter-wise or argument-wise).
>>
>> Lexical order of course.
>
> Lexical order of the definition or the caller?
>
> So far we have 1 for the caller and 1 for the definition. Both seem to think their choice is the obviously correct one :)
>
>   > Patrick Schluter:
>   > They are in the order of declaration of the function...There's no reason to evaluate it any other order as the code generation requires that the caller populates the registers/stack in the order the function expects.
>
>   > Paul Backus:
>   > Personally, I think the obviously-correct choice is to evaluate them in lexical order (i.e., order of the call).

That's probably a bottom up vs top down perception of things. When you learned the stuff at the assembly/object level you tend to see the things in cpu perspective, and there you tend to see the call convention for what it is pushing register in a specific order.
If you came from the high level application level where the machine implementation is nothing more than a detail, you tend to don't care about the hoops the compiler/implementation has to go through to realize the abstraction the language presents (best example is the set types in Pascal where the elegance of 'if c in [a..z]' was loved by programmers, but resulted in an incredibly complex code).

This said, the lexical order is after all the more abstract one and the complexity of it is imo manageable by the compiler so there's nothing that should preclude it, even if in my mental model that is closer to the implementation, would see callee order first.

June 10, 2019
On Mon, Jun 10, 2019 at 06:28:38PM +0000, Patrick Schluter via Digitalmars-d wrote: [...]
> If you came from the high level application level where the machine implementation is nothing more than a detail, you tend to don't care about the hoops the compiler/implementation has to go through to realize the abstraction the language presents (best example is the set types in Pascal where the elegance of 'if c in [a..z]' was loved by programmers, but resulted in an incredibly complex code).

Not disagreeing here, but couldn't resist the obligatory quote:

	People who are more than casually interested in computers should
	have at least some idea of what the underlying hardware is like.
	Otherwise the programs they write will be pretty weird.
	-- D. Knuth


T

-- 
Some days you win; most days you lose.
June 10, 2019
On 10.06.19 20:28, Patrick Schluter wrote:
> On Sunday, 9 June 2019 at 21:01:35 UTC, Jonathan Marler wrote:
>> On Sunday, 9 June 2019 at 19:43:54 UTC, Andrei Alexandrescu wrote:
>>> On 6/9/19 7:27 AM, aliak wrote:
>>>> With reorderable, as Walter pointed out, what't the order (parameter-wise or argument-wise).
>>>
>>> Lexical order of course.
>>
>> Lexical order of the definition or the caller?
>>
>> So far we have 1 for the caller and 1 for the definition. Both seem to think their choice is the obviously correct one :)
>>
>>   > Patrick Schluter:
>>   > They are in the order of declaration of the function...There's no reason to evaluate it any other order as the code generation requires that the caller populates the registers/stack in the order the function expects.
>>
>>   > Paul Backus:
>>   > Personally, I think the obviously-correct choice is to evaluate them in lexical order (i.e., order of the call).
> 
> That's probably a bottom up vs top down perception of things. When you learned the stuff at the assembly/object level you tend to see the things in cpu perspective, and there you tend to see the call convention 

With C compilers, where order of evaluation is arbitrary, usually you will see compilers using /reverse/ order.

> for what it is pushing register in a specific order.

This does not really make a lot of sense. Why would there be a preferred order to push registers that influences preferred order of arguments? The actual point is that for /some subset/ of the arguments (those that are actually pushed onto the stack instead of passed in registers), the calling convention will specify in which order they have to end up on the stack. But there is no rule that says you have to evaluate side-effects of arguments in the order they will end up on the stack!

> If you came from the high level application level where the machine implementation is nothing more than a detail, you tend to don't care about the hoops the compiler/implementation has to go through to realize the abstraction the language presents (best example is the set types in Pascal where the elegance of 'if c in [a..z]' was loved by programmers, but resulted in an incredibly complex code).
> ...

I.e., some old Pascal compiler sucked.

> This said, the lexical order is after all the more abstract one and the complexity of it is imo manageable by the compiler so there's nothing that should preclude it, even if in my mental model that is closer to the implementation, would see callee order first.
> 

A good programmer understands multiple levels of abstraction at the same time, and evaluating in order of formal parameters is not actually "closer to the implementation". Furthermore, you can always change the evaluation order by defining some temporaries, if you think some other order will allow the compiler to do a better job using the limited available static information.