Jump to page: 1 212  
Page
Thread overview
Discussion: Rvalue refs and a Move construtor for D
Aug 28
Suleyman
Aug 29
Manu
Aug 29
Suleyman
Aug 29
Manu
Aug 29
Manu
Aug 29
kinke
Aug 29
kinke
Aug 31
Suleyman
Sep 01
Suleyman
Sep 02
Manu
Sep 03
Suleyman
Sep 03
Manu
Sep 03
Suleyman
Sep 03
Suleyman
Sep 03
Manu
Sep 04
kinke
Sep 04
Exil
Sep 04
Manu
Sep 04
Suleyman
Sep 04
Manu
Sep 04
kinke
Sep 04
Manu
Sep 04
Exil
Sep 04
kinke
Sep 05
kinke
Sep 05
Suleyman
Sep 05
kinke
Sep 05
Suleyman
Sep 05
kinke
Sep 05
Exil
Sep 05
kinke
Sep 05
kinke
Sep 05
Suleyman
Sep 05
Suleyman
Sep 05
kinke
Sep 05
Manu
Sep 05
kinke
Sep 05
Manu
Sep 05
kinke
Sep 06
Suleyman
Sep 06
kinke
Sep 06
Manu
Sep 06
kinke
Sep 06
Suleyman
Sep 06
Manu
Sep 06
Suleyman
Sep 07
Manu
Sep 07
Suleyman
Sep 07
Manu
Sep 07
Suleyman
Sep 06
Manu
Sep 06
Suleyman
Sep 07
kinke
Sep 07
kinke
Sep 07
Suleyman
Sep 07
Suleyman
Sep 07
kinke
Sep 07
Suleyman
Sep 07
Manu
Sep 07
Manu
Sep 08
Suleyman
Sep 08
Manu
Sep 08
Suleyman
Sep 08
Manu
Sep 08
Suleyman
Sep 08
Suleyman
Sep 08
Manu
Sep 08
Suleyman
Sep 08
Suleyman
Sep 09
Manu
Sep 09
Suleyman
Sep 09
Manu
Sep 09
Suleyman
Sep 09
Suleyman
Sep 09
Manu
Sep 08
Suleyman
Sep 06
Manu
Sep 06
kinke
Sep 06
kinke
Sep 06
Manu
Sep 05
kinke
Sep 05
Manu
Sep 05
kinke
Sep 05
Manu
Sep 05
Suleyman
Sep 05
Manu
Sep 04
Suleyman
Sep 04
kinke
Sep 04
Suleyman
Sep 04
Suleyman
Sep 05
Suleyman
Sep 05
Suleyman
Sep 04
Manu
Sep 04
Suleyman
Sep 04
Manu
Sep 04
kinke
Sep 04
kinke
Sep 04
Manu
Sep 04
Suleyman
Sep 04
a11e99z
Sep 04
a11e99z
Sep 04
RazvanN
Sep 04
Suleyman
Sep 05
RazvanN
Sep 05
Suleyman
Sep 03
Manu
Aug 29
RazvanN
Aug 29
kinke
August 28
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.

August 29
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
August 29
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
August 29
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.

August 28
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.
August 28
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.
August 29
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
August 29
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.
August 29
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
August 29
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?
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11