[Issue 17448] Move semantics cause memory corruption and cryptic bugs

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=17448

--- Comment #36 from Shachar Shemesh <shachar at weka.io> ---
Hello Walter,

I see two problems with your comment. The first is that I think you are missing
the real point of this bug report. It is not about controlling movability. It
is about being able to hook the object's lifetime.

The second problem is that I think you are trying to use optimization as a tool
for solving semantic problems. I take issue with that, as there are always
cases where optimizations are not possible.

(In reply to Walter Bright from comment #35)
> Why was it moving the stack allocated objects in these examples? Because
> when it went out of scope, it is safe to assume that there are no extant
> pointers to it.

Before an object goes out of scope, its destructor needs to be called. Else,
you give me no tool to make sure the above assertion is actually true.

In this case, the object "went out of scope" but its destructor was not called.
This is the real trigger for the dangling external pointer.

> This is why the compiler (now) complains when the code
> registers a pointer to the stack object. Of course, making the code @trusted
> enables code like this to be written, leaving it up to the programmer to
> ensure the safety.

I have no problem with the saying that some code that is safe is not @safe. My
issue is with saying that I am facing a lifetime management problem that has no
solution within the language, no matter how aware I am of it.

> But there's another wrinkle. With RVO (Return Value Optimization)
...

There are cases where it is impossible to RVO:

SomeStruct func(bool which) {
  SomeStruct struct1, struct2;

  // Do something on both struct1 and struct2 to make this meaningful.
  if( which )
    return struct1;
  else
    return struct2;
}

There is simply no way to allocate the correct object on the caller's memory.

> So, to guarantee RVO:
...

That's, to me, missing the point. The point, for me, is to be able to design a
struct that will be safe without asking the users of the struct to live up to
some conditions. I don't think anything else is a viable answer.

> Obviously, I am not familiar with your code and usage patterns. But the
> above ought to offer some hope (!) for getting your code working properly.

RVO is important, and definitely a welcome enhancement. The issue here,
however, is not about Weka's code (the bug that triggered this bug report is
long solved now). The point here is that there is an exceedingly useful tool
designed to create code that is easier to maintain that D makes impossible.

I am going to write a DIP for introducing a mechanism for hooking the move, as
discussed in comment #31. There reason I'm keeping this discussion alive is
because I will need your buy-in to get it integrated, and for that I need you
to see the need.

> If there are more pernicious problems with moving that aren't covered by
> this, please let me know. Perhaps I can think of a solution.

See above.

--