Hello everybody.


Recently D adpoted the copy constructor, the postblit is deprecated, and the postmove (DIP 1014) is also deprecated since it has the same problems as the postblit.

I am planning in this SOAC of 2019 to work on an alternative to the postmove (DIP 1014) which will be similar to C++' move constructor and move assignment operator. But in C++ these take an rvalue ref argument which we don't have in D (yet).

Move operations are already done by the compiler whether we have rvalue ref or not.

The move constructor and the move assignment operator can be made in D with or without rvalue refs. Here a short comparison of both scenarios.

## With rvalue ref

Example:
```
struct S
{
    this(@rvalue ref S) { /* move constructor */ }
    auto opAssign(@rvalue ref S) { /* move op assign */ }
}
```

* Pros:
 - seems natural: doesn't smell like compiler magic (but it still is compiler magic, at least until D adopts implicit constructors)
 - overloadable with other constructors and opAssign declarations

*Cons
 - requires adding rvalue ref to the language

## Without rvalue refs

Example:
```
struct S
{
    __move_ctor(ref S) { /* move constructor */ }
    auto opMoveAssign(ref S) { /* move op assign */ }
}
```

* Pros:
 - doesn't require extra features in the language

* Cons:
 - ugly constructor name: otherwise it would clash with the copy constructor.
 - doesn't overload with regular constructor or regular opAssign


Give me your thoughts on which way you prefer. And most importantly I want you to convince me why adding rvalue refs is good for D because there aren't many use cases that I know of.

On Wednesday, 28 August 2019 at 23:32:01 UTC, Suleyman wrote:

> The move constructor and the move assignment operator can be made in D with or without rvalue refs. Here a short comparison of both scenarios.
>
> ## With rvalue ref
>
> Example:
> ```
> struct S
> {
>     this(@rvalue ref S) { /* move constructor */ }
>     auto opAssign(@rvalue ref S) { /* move op assign */ }
> }
> ```
>
> * Pros:
>  - seems natural: doesn't smell like compiler magic (but it still is compiler magic, at least until D adopts implicit constructors)

There are some of us that would really like implicit constructors (done right; not like C++) for other use cases. How would implicit constructors help this situation, and should it be included as part of this proposal?

Mike

On Wednesday, 28 August 2019 at 23:32:01 UTC, Suleyman wrote:

> Give me your thoughts on which way you prefer. And most importantly I want you to convince me why adding rvalue refs is good for D because there aren't many use cases that I know of.

The proposals presented seem to focus primarily on move semantics, but one of the other issues rvalue references aimed to solve was perfect forwarding.  How does D do perfect forwarding with your proposal or without rvalue references?

Mike

On Thursday, 29 August 2019 at 01:01:36 UTC, Mike Franklin wrote:
> The proposals presented seem to focus primarily on move semantics, but one of the other issues rvalue references aimed to solve was perfect forwarding.  How does D do perfect forwarding with your proposal or without rvalue references?
>
> Mike

I discussed this with Manu which is pro rvalue ref and he made a lot of good points, the most important thing is that rvalue ref would drastically simplify the implementation of `core.lifetime.move()`.

But he pointed out that auto ref already does perfect forwarding.

On Wed, Aug 28, 2019 at 5:15 PM Mike Franklin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 28 August 2019 at 23:32:01 UTC, Suleyman wrote:
>
> > The move constructor and the move assignment operator can be made in D with or without rvalue refs. Here a short comparison of both scenarios.
> >
> > ## With rvalue ref
> >
> > Example:
> > ```
> > struct S
> > {
> >     this(@rvalue ref S) { /* move constructor */ }
> >     auto opAssign(@rvalue ref S) { /* move op assign */ }
> > }
> > ```
> >
> > * Pros:
> >  - seems natural: doesn't smell like compiler magic (but it
> > still is compiler magic, at least until D adopts implicit
> > constructors)
>
> There are some of us that would really like implicit constructors (done right; not like C++) for other use cases. How would implicit constructors help this situation, and should it be included as part of this proposal?

@implicit constructors should have been part of the copy-ctor proposal, which I argued at the time... but it wasn't so it's effectively an unrelated DIP now.

On Wed, Aug 28, 2019 at 8:45 PM Suleyman via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Thursday, 29 August 2019 at 01:01:36 UTC, Mike Franklin wrote:
> > The proposals presented seem to focus primarily on move semantics, but one of the other issues rvalue references aimed to solve was perfect forwarding.  How does D do perfect forwarding with your proposal or without rvalue references?
> >
> > Mike
>
> I discussed this with Manu which is pro rvalue ref and he made a lot of good points, the most important thing is that rvalue ref would drastically simplify the implementation of `core.lifetime.move()`.
>
> But he pointed out that auto ref already does perfect forwarding.

It's a _part_ of perfect forwarding; the part that allows a function
to receive forwarded arguments.
The other part is a `forward` implementation passes them forward (and
actually works), and that depends on a `move` implementation that
works.
Perfect forwarding in D would be a combination of `auto ref` and `forward`.
We have all the concepts we need, so I don't think that's actually
related to this topic. If we define non-trivial move, those forwarding
concepts should certainly map, or the proposal would fail instantly.

On Wednesday, 28 August 2019 at 23:32:01 UTC, Suleyman wrote:
> [...]
>
> Recently D adpoted the copy constructor, the postblit is deprecated, and
> the postmove (DIP 1014) is also deprecated since it has the same
> problems as the postblit.

Please don't forget to explicitly deprecate DIP 1014 in your DIP if you
end up writing one, because it is not formally deprecated yet.

> [...]
>
> Give me your thoughts on which way you prefer. And most importantly I
> want you to convince me why adding rvalue refs is good for D because
> there aren't many use cases that I know of.

Some major reasons: C++ interop, perfect forwarding, movable but
non-copyable types (e.g. C++'s `std::unique_ptr`), cheaper reference
counting.

This is a good summary on rvalue references in C++:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2027.html

On Wednesday, 28 August 2019 at 23:32:01 UTC, Suleyman wrote:
> Give me your thoughts on which way you prefer. And most importantly I want you to convince me why adding rvalue refs is good for D because there aren't many use cases that I know of.

An alternative solution to rvalue refs would be uniqueness semantics, which is how Rust solves move assignment (you can't move a variable's contents if it's being borrowed).

Problem: D currently doesn't have baked-in unique references.

On Wednesday, 28 August 2019 at 23:32:01 UTC, Suleyman wrote:
> Hello everybody.
>
>
> Recently D adpoted the copy constructor, the postblit is deprecated, and the postmove (DIP 1014) is also deprecated since it has the same problems as the postblit.
>
> [...]

I would like to point out that I have been working on a move constructor DIP [1]. It's not ready for review yet, but the backbone it there. We can unite efforts to get this to the finish line. As you can see, my DIP discusses perfect forwarding.

[1] https://github.com/RazvanN7/DIPs/blob/Move_Constructor/DIPs/DIP1xxx-rn.md

On Thursday, 29 August 2019 at 04:38:03 UTC, Manu wrote:
> On Wed, Aug 28, 2019 at 8:45 PM Suleyman via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> On Thursday, 29 August 2019 at 01:01:36 UTC, Mike Franklin wrote:
>> > [...]
>>
>> I discussed this with Manu which is pro rvalue ref and he made a lot of good points, the most important thing is that rvalue ref would drastically simplify the implementation of `core.lifetime.move()`.
>>
>> But he pointed out that auto ref already does perfect forwarding.
>
> It's a _part_ of perfect forwarding; the part that allows a function
> to receive forwarded arguments.
> The other part is a `forward` implementation passes them forward (and
> actually works), and that depends on a `move` implementation that
> works.

What's wrong with the current `move` and `forward` implementations?