Isolated by example

[via Digitalmars-d]

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.