On Friday, 2 May 2014 at 09:41:48 UTC, Marc Schütz wrote:
To make this more useful, turn it into a requirement. It gets
us deterministic destruction for reference types. Example:
...
isolated tmp = new Tempfile();
// use tmp
...
// tmp is guaranteed to get cleaned up
}
No because...
This needs more elaboration. The problem is control flow:
isolated a = new A();
if(...) {
immutable b = a;
...
}
a.foo(); // <-- ???
(Similar for loops and gotos.)
There are several possibilities:
Of this.
1) isolateds must be consumed either in every branch or in no
branch, and this is statically enforced by the compiler.
2) It's just "forbidden", but the compiler doesn't guarantee it
except where it can.
3) The compiler inserts a hidden variable to track the status
of the isolated, and asserts if it is used while it's in an
invalid state. This can be elided if it can be proven to be
unnecessary.
These solutions are all unnecessary restrictive. If the variable
may be consumed it is consumed. This is a problem solved for ages
for non nullables, there is no need to brainstorm here.
I would prefer 3), as it is the most flexible. I also believe a
similar runtime check is done in other situations (to guard
against return of locals in @safe code, IIRC).
3 is idiotic as the compiler can't ensure anything at compile
time. Random failure at runtime for valid code is not desirable.
