Am 03.02.2016 um 16:29 schrieb Ola Fosheim Grøstad:
On Wednesday, 3 February 2016 at 15:05:39 UTC, Sönke Ludwig wrote:
For std.move, isn't the only place where an exception can be thrown in
the destructor (which shouldn't throw)? It uses memcpy to move the
memory around to circumvent any extended construction logic.
Not sure if you are talking about something else, but in C++ if you do
"somefunction(std::move(resource))"
then somefunction can throw and the resource remains untouched (if
implemented in a reasonable fashion).
In D, std.move(...) has this implementation:
private T moveImpl(T)(ref T source)
{
T result = void;
moveEmplace(source, result);
return result;
}
So clearly by the time somefunction is called, the resource is already
moved and an exception will cause permanent damage?
Hmm, that's true, it would get destroyed and you'd have to let
somefunction take the argument by reference to avoid that. But in
general I don't see an issue with this. Once the value is moved into the
context of somefunction, somefunction has ownership and needs to take
care of where the value goes - seems like pretty clear semantics. And in
C++ you'd have the same situation once somefunction decides to move/swap
the value somewhere else before throwing an exception.
