On Friday, 2 May 2014 at 17:46:54 UTC, deadalnix wrote:
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 think the situation is different here. For nullables, you
wouldn't gain much by more precise tracking. For isolated, as
noted, we'd gain deterministic lifetimes for reference types.
This is IMO important enough to accept a few minor complications
(which are anyway solvable). There would be no more need for the
unsafe std.typecons.scoped, which only works for classes anyway,
but not slices or pointers.
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.
You can in most cases. Runtime failure is only for the cases
where it's not possible.
Random failure at runtime for valid code is not desirable.
It's not random, and the code was _not_ valid: it tried to use a
consumed isolated.
