[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 #25 from Andrei Alexandrescu <andrei at erdani.com> ---
(In reply to Tomer Filiba (weka) from comment #24)
> > We should address this situation by having writeln take scope inputs. It does
> > not escape any pointers.
> 
> So... more special cases?

That's a straight use of scope per DIP 1000, in fact the very design intent:
scope in a function signature specifies the function won't escape the
parameter.

> > 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.

What I'm saying is the problem is different: the address of this should not
escape a non-scope method (including the constructor), we're in a world of
trouble regardless whether we introduce a new feature regarding movability.

--