On 5/26/2021 8:29 AM, Paul Backus wrote:
> Of course, D's vision here is severely hampered in practice by the poor quality of its documentation (raise your hand if you can explain what ["return ref parameter semantics with additional scope parameter semantics"][1] actually means). But that's the idea.
> 
> [1]: https://dlang.org/spec/function.html#ref-return-scope-parameters

The beauty of open source is anyone can submit PRs to improve it!

On 5/26/2021 5:44 PM, tsbockman wrote:
> Why must it always be the first parameter, instead of always being the last parameter, etc.? The choice of **which** parameter gets special treatment is arbitrary, and is the part I was complaining about because of how it interacts with UFCS.

It is not arbitrary. It actually fits with common Phobos usage. It is especially true if one writes member functions for a container, doing things like:

   stack.push(value);

where value is a pointer.

On 5/25/2021 4:24 AM, Dennis wrote:
> [...]

Thanks for a good explanation of the issue. Well done!

In practice from what I see, the normal use is:

   stack.push(value)
   container.add(element)
   array.append(element)
   buffer.write(value)

and rather overwhelmingly so, although I did not collect statistics. (The `this` reference is considered the first parameter.)

The move example is one counterexample.

There's tremendous value in doing the common case in a simple manner, rather than trying to accommodate every case by adding a great deal of complexity to the language and compiler. There's value not just in simplicity, but a follow on effect in having diverse code organized in predictable ways.

Hence a simple solution:

Make move() @trusted.

Write an @safe alternative to move() with the parameters swapped.

On 11.06.21 04:58, Walter Bright wrote:
> It is not arbitrary. It actually fits with common Phobos usage. It is especially true if one writes member functions for a container, doing things like:
> 
>     stack.push(value);
> 
> where value is a pointer.

You can't defend the "first parameter" rule with member functions. If you want to support returning through `this`, you can easily define that without bringing the order of the parameters into it.

The actual point of the "first parameter" rule is obviously UFCS. You want support a free function `push` that is called via UFCS. `push` is not a member function then.

On 6/10/2021 10:53 PM, ag0aep6g wrote:
> You can't defend the "first parameter" rule with member functions. If you want to support returning through `this`, you can easily define that without bringing the order of the parameters into it.
> The actual point of the "first parameter" rule is obviously UFCS. You want support a free function `push` that is called via UFCS. `push` is not a member function then.

The whole idea of UFCS is member functions and regular functions are interchangeable, hence `this` is the first parameter.

On 6/10/2021 10:53 PM, ag0aep6g wrote:
> [...]

BTW, another "first parameter" rule is assignment operators:

   a += b;
   a ~= b;
   a = b;

The right side (second parameter) is assigned to the left side (first parameter).

On Saturday, 29 May 2021 at 12:32:49 UTC, Paulo Pinto wrote:
> On Thursday, 27 May 2021 at 20:21:58 UTC, Ola Fosheim Grostad wrote:
>> I know that lifetime annotations predates Rust, I think it was used in a ML dialect.
> It goes back to Cyclone, https://cyclone.thelanguage.org/

Also clean (https://clean.cs.ru.nl/Clean).  Don't know which came first, but clean is certainly more of an ml (cyclone is almost backwards-compatible with c).