Isolated by example
deadalnix via Digitalmars-d
digitalmars-d at puremagic.com
Fri May 2 10:46:53 PDT 2014
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.
More information about the Digitalmars-d
mailing list