Thread overview | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
August 28, 2019 Discussion: Rvalue refs and a Move construtor for D | ||||
---|---|---|---|---|
| ||||
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, 2019 Re: Discussion: Rvalue refs and a Move construtor for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Suleyman | 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, 2019 Re: Discussion: Rvalue refs and a Move construtor for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Suleyman | 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, 2019 Re: Discussion: Rvalue refs and a Move construtor for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Franklin | 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, 2019 Re: Discussion: Rvalue refs and a Move construtor for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Franklin | 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, 2019 Re: Discussion: Rvalue refs and a Move construtor for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Suleyman | 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, 2019 Re: Discussion: Rvalue refs and a Move construtor for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Suleyman | 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, 2019 Re: Discussion: Rvalue refs and a Move construtor for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Suleyman | 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, 2019 Re: Discussion: Rvalue refs and a Move construtor for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Suleyman | 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, 2019 Re: Discussion: Rvalue refs and a Move construtor for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | 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?
|
Copyright © 1999-2021 by the D Language Foundation