[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 #23 from Andrei Alexandrescu <andrei at erdani.com> ---
(In reply to Tomer Filiba (weka) from comment #21)
> Walter, the @safe-ty aspects of the issue are one thing. In real code, @safe
> is hardly workable, i.e.
> 
> void main() {
>     int x;
>     writeln(&x);    // Error: cannot take address of local `x` in `@safe`
> function `main`
> }

We should address this situation by having writeln take scope inputs. It does
not escape any pointers.

> It's either you go whole nine yards and implement a full-blown
> borrow-checker like rust, or impose very strict (and sometimes arbitrary)
> limitations that practically make it unusable.

We believe there's a third way, but the burden of proof is indeed on us.

> But @safe-aside, the *more important* aspect here that the compiler must
> provide a guarantee of *never moving* structs that are marked `@disable
> this(this)` or `pragma(immovable)` or with any other syntax. It's a semantic
> contract with the compiler, not an optimization.
> 
> So for example, a desired outcome might be for this not to compile:
> 
> pragma(immovable) struct S {
>     int x;
> }
> S func() {
>     return S(100);
> }
> void main() {
>     S s = func();
> }
> 
> Should the compile be unable to rewrite this as pass-by-reference. 
> 
> I hope it makes the problem clear, again, @safe is really not the issue
> here. It's the guarantees provided by move semantics.

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.

(Thinking of supporting the notion of immovable objects - it would have huge
ripples. Already supporting structs with @disable this(); and/or @disable
this(this); in the standard library is a recurring (and still ongoing)
nightmare. Dealing with immovability on top of that would make a lot of code a
lot heavier.)

--