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