Discussion: Rvalue refs and a Move construtor for D
Eduard Staniloiu
edi33416 at gmail.com
Thu Sep 5 12:09:33 UTC 2019
On Wednesday, 4 September 2019 at 21:59:46 UTC, kinke wrote:
> On Wednesday, 4 September 2019 at 21:09:27 UTC, Exil wrote:
>> So you change the ABI to pass by a pointer to the object on
>> the stack. In cases where we use some "move" intrinsic, a
>> pointer to a lvalue (passed in to the move()) is passed in
>> place of the pointer to the object on the stack?
>
> Yes.
>
>> Because of this, even though the function doesn't use a
>> reference. It could unknowingly change state outside of the
>> scope of the function. That'll entirely depend on the use if
>> they mistakenly use `move()` where they didn't mean to.
>
> Yes, the assumption being that people do use `move` when they
> mean to (it's explicit after all) and are fine with not being
> able to make any assumptions about its state after the move.
> Re-assigning would still be possible.
>
> But as stated further up, the crux is probably the lifetime for
> moved lvalues, i.e., the by-value parameter not being destroyed
> right before/after returning, but when the moved-from lvalue
> goes out of scope.
> Maybe we could destruct the moved-from lvalue after the call
> and reset it to `T.init`. It would be destroyed a 2nd time when
> going out of scope.
So you are saying that Exil's example
```
void main()
{
Foo lvalue;
lvalue.value = 0;
bar(move(lvalue)); // intrinsic move
assert(lvalue.value == 10); // passes
}
```
would be valid and it's ok?
I'm sorry, but, in my humble opinion, this would be horrible.
I would expect the contents of the moved lvalue to be reset to
`Foo.init`.
I think the behavior shown above would be error prone and a big
source of bugs.
Edi
More information about the Digitalmars-d
mailing list