On Wednesday, 3 October 2018 at 14:07:58 UTC, Shachar Shemesh
wrote:
On 03/10/18 16:56, Stanislav Blinov wrote:
struct S {
this(S rhs);
OMG, that's so simple!!! Why didn't I think of it?
Oh wait, I did.
Now I see why sometimes your posts are greeted with hostility.
And this simply and utterly doesn't work.
If you read the DIP, you will notice that the *address* in
which the old instance resides is quite important for
performing the actual move. This is not available with the
interface you're suggesting, mainly because by the time you
have rhs, it has already moved.
In other words, for the interface above to work, the type must
already be movable, which kinda contradict what we're trying to
achieve here.
In the presence of such a constructor, the compiler will have to
call it every time it moves the value, same as what you're
proposing for __move_post_blt. This obviates the need of an
address: address of the argument will always already be
sufficient, even though it's not ref, as the chain of calls for
this(S) will inevitably start with the address of something
constructed in place.
in C++ would have an equivalent signature of
ReturnType foo(Type&& x); // NOT ReturnType foo(Type x);
No, it is not. You see, in C++, x is an "rvalue *reference*". x
has not moved by this point in the run, it has simply had its
address passed to foo.
You've misunderstood me. Yes, in C++ there's an obvious
difference between pass-by-value and pass-by-rvalue-reference,
and it is always user's responsibility to write a move ctor. Not
so in D. In D, you can always assume that anything passed by
value *is* an rvalue reference, precisely because of D's take on
move semantics. I.e. any argument passed by value can assumed to
be moved or constructed in place (that's the main difference from
C++, where it must be explicitly specified).
