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