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

Tomer Filiba (weka) <to...@weka.io> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |---

--- Comment #21 from Tomer Filiba (weka) <to...@weka.io> ---
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`
}

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.

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.

--

Reply via email to