advise about safety of using move in an opAssign with __traits(isRef
aliak
something at something.com
Fri Aug 16 08:07:28 UTC 2019
Hi, I'm trying to fix a use-case where you have a wrapper
template type (it's an optional) and the wrapping type has
@disable this(this). And having this scenario work:
struct S {
@disable this(this);
}
Optional!S fun() {...}
Optional!S a;
a = fun.move;
Now that won't work because of the disabled copy, but you can
either:
1) Add an explicit move function in the Optional type:
struct Optional {
auto move(ref Optional!T target) {
import std.algorithm: move;
return move(this, target);
}
}
Then you could do:
fun.move(field);
First of all I find the readability confusing, so there's no way
to know if fun is moving in to field or field is moving in to
fun. But OTOH it matches the phobos move(T src, T target). So
conventionally maybe ok. Also it's explicit, so it makes it clear
at the call site that a move is happening.
2) use isRef inside opAssign like this:
void opAssign(auto ref Optional!T lhs) {
static if (__traits(isRef, lhs)) {
this._value = lhs._value;
} else {
import std.algorithm: move;
move(lhs._value, this._value);
}
}
Then you could just do:
field = fun
And it'll just work since fun returns an rvalue. The second
solution it seems like it'll just work correctly with the static
if guard. But I'm not sure if there're any gotchas I should be
aware of?
Any advice?
More information about the Digitalmars-d-learn
mailing list