My Reference Safety System (DIP???)

[Zach the Mystic via Digitalmars-d]

On Friday, 27 February 2015 at 00:44:21 UTC, deadalnix wrote:
> On Thursday, 26 February 2015 at 22:45:19 UTC, Zach the Mystic 
> wrote:
>> I'm starting to see what you mean. I guess it's only 
>> applicable to variables with double (or more) indirections 
>> (e.g. T**, T***, etc.), since only they can lose information 
>> with transitive scopes. Looks like we need a new rule: 
>> variables assigning to one of their double indirections cannot 
>> acquire a scope-depth greater than (or lifetime less than) 
>> their current one. Does that fix the problem?
>
> Cool. I think that can work (I'm not 100% convinced, but at 
> least something close to that should work). But that is 
> probably too limiting.
>
> Hence the proposed differentiation of lvalue and rvalues.

Yeah, wasn't completely clear. I meant to say:

Variables assigning to one of their double indirections cannot 
acquire a scope-depth greater than (or lifetime less than) their 
current longest-lived one. Also, bear in mind, a parameter could 
be an "lvalue":

void fun(T* a, T** b) {
   *b = a;
}

I guess its just better to use "source" and "targer" than lvalue 
and rvalue.

Also bear in mind that in the worst case scenario, any code can 
be made to work by putting it into the newly approved-of idiom: 
The @trusted Lambda! We want a safety mechanism conservative 
enough to catch all failures, accurate enough to avoid too many 
false positives (thus minimizing @trusted lambdas), easy enough 
to implement, and which doesn't tax compile time too heavily. The 
magic Four! I still have a few doubts (recursive inference, for 
example, which can probably be improved), but not too many.