[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 #24 from Tomer Filiba (weka) <tomer at weka.io> ---
> We should address this situation by having writeln take scope inputs. It does
> not escape any pointers.

So... more special cases?

> I think immovability is a red herring. The problem is a pointer is escaped
> and it shouldn't be. Even if the struct were immovable, you could construct
> other cases in which &this gets messed up.

Of course I could *make* it fail, but that would require me doing memcpy or
what not. It escapes the type system. I'm trying to make it work or fail inside
the type system.

The whole point is that `struct S` cannot tell how people will use it. The
author thought people would just do

void func() {
    auto s = S(100);
    // ...
    // when s goes out of scope it will cancel the callback
}

The author tried to prevent people from shooting themselves in the foot by
making the struct immovable. But then someone added a wrapper function that
returns a `struct S`. This second author knew the struct is immovable and
trusted the type system so his changes would either not compile, or compile but
  never move the object. The code works in the happy flow, but when things go
south, all of the sudden you get cryptic bugs that take many days -- and a lot
of luck -- to track down.

In this specific example, the struct registers a timer to be called in XX
seconds and kill the operation. Other examples could be a struct that adds
itself to a link-list and removes itself when it's destroyed. 

It doesn't make sense that C++ gives me this guarantee, but D fools me into
thinking my code is okay when in fact it isn't. It's not an implementation
detail or an optimization -- it's a semantic guarantee.

--