DIP69 - Implement scope for escape proof references

via Digitalmars-d digitalmars-d at puremagic.com
Mon Dec 15 03:23:27 PST 2014


On Monday, 15 December 2014 at 01:44:27 UTC, Dicebot wrote:
> On Saturday, 13 December 2014 at 00:10:07 UTC, Walter Bright 
> wrote:
>> The proposal provides escape proof passing of arguments. This 
>> is necessary in order to make rc safe, for example.
>>
>> What are you looking for?
>
> I am looking for a tool to prevent escaping references to 
> user-defined entities / resources from specific scope. RC case 
> is not interesting at all to me though I recognize the 
> potential benefits of tweaking the scope system to help with 
> it. But there is a big difference between tweak for one 
> specific use case or designing feature around it (so it becomes 
> almost useless in other cases).
>
> I have already provided you an example of code I want to be 
> enforced with scope and two major issues with existing proposal 
> that make it lacking. This example is akin to litmus test for 
> any scope proposal - if it doesn't allow to express such 
> design, that proposal is simply not good enough.
>
> In case you have forgotten, I am reminding about two critical 
> points that are necessary to make it fly:
>
> 1) inout analog for scope to be able to deduce borrowship of 
> return values based on borrowship of input arguments. Current 
> system is conservative and results in template bloat 
> (complicated by the fact that it is storage class thus not 
> actually part of a type)

Is it be possible to make `inout` a more general tool for type 
erasure? I don't think yet another ad-hoc mechanism should be 
introduced.

>
> 2) at least optional transitivity to be able to express to 
> protect with scope data referenced by slice or owned linked 
> list referenced from root node.
>
> ------
>
> In your tree example I would have never wanted scope protection 
> of one specific node of such tree - but a transitive scope 
> protection of whole tree view available through on of node 
> pointers/references. It doesn't matter who and how owns the 
> data for borrowship implementation - only thing that matters 
> that _it is not me_.

I think there are two cases that are relevant. 1) the tree nodes 
don't own their children, instead they are managed by - let's say 
- a region allocator, and 2) the tree nodes do own their 
children. In both cases, they can declare the children as scope 
members (assuming a proposal that allows that).

The only case I can think of where the children should not be 
scope members is when they are GC managed. But in this case, you 
don't need to worry about references to them escaping.

Therefore, I don't see a use case for transitivity of scope, from 
a conceptional point of view. If a particular design makes 
transitivity necessary, this points to a flaw in the design, IMO.


More information about the Digitalmars-d mailing list