June 01, 2021

On Thursday, 27 May 2021 at 19:03:53 UTC, Joseph Rushton Wakeling wrote:

>

On Wednesday, 26 May 2021 at 12:36:42 UTC, Atila Neves wrote:

>

[...]

I understand that motivation, but at the same time, it's not necessarily good to reduce flexibility for the programmer. I think I would rather have to clearly annotate my target ref/out parameters every time, than rely on a "magic" rule like "the first parameter is the targeted one".

[...]

I agree with all of this. The problem is of course that pesky idea that will neatly tie everything up.

June 10, 2021
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!
June 10, 2021
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.
June 10, 2021
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.

June 11, 2021
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.
June 11, 2021
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.
June 11, 2021
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).
June 11, 2021
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).
June 11, 2021

On Friday, 11 June 2021 at 03:12:29 UTC, Walter Bright wrote:

>

Hence a simple solution:

Make move() @trusted.

I don't think that makes sense. move is @safe anyway for non-scope inputs, and for scope inputs you wouldn't want it to lie about its interface (pretending it's scope when it isn't). Also you don't want it to call a @system move constructor in @safe code.

>

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

What would that alternative be called?

June 11, 2021

On Saturday, 29 May 2021 at 11:32:50 UTC, Dennis wrote:

>

On Tuesday, 25 May 2021 at 11:24:59 UTC, Dennis wrote:

>

We want to express:

//                       ┌─────────>─────────┐
void move(T)(return T source, ref scope T target)

Here's a simple extension idea: https://github.com/dlang/dmd/pull/12601

Simply skip over return parameters when looking for the 'first' parameter, since making a return parameter its own destination has no use. It's still constraining the parameter order, but may be good enough to move forward with move.

This is the way to go IMO.

The potential problem is that if we later on decide we need a more complex solution, it's going to be more complicated than if we do it now. So we kind of have to choose right away unless we want move2.

Still, ignoring return ref when choosing the output argument sounds the best compromise for me.