DIP69 - Implement scope for escape proof references

[via Digitalmars-d]

On Monday, 15 December 2014 at 11:32:11 UTC, Dicebot wrote:
> On Monday, 15 December 2014 at 11:23:28 UTC, Marc Schütz wrote:
>> 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.
>
> Actually I think in neither case children should be declared as 
> scope members. Instead those should be declared as private 
> members but methods that return pointers/references to children 
> would be declared to return (transitive) scope 
> pointers/references.

I see this as the same thing, conceptually (module the 
"transitive" in in your parentheses). It's just a different 
mechanism. Scope members are just a short-cut instead of writing 
an accessor method that returns scope.

>
> For me "scopeness" is a property of "view", not object itself - 
> this also makes ownership method of actual data irrelevant.

Yes, and this would be true for scope members just the same. (If 
the aggregate "owns" it's scope members, it will however get in 
trouble when it tries to free() them, therefore your mechanism is 
more appropriate in this case.)

> Only difference between GC owned data and stack allocated one 
> is that former can have scoped view optionally but for the 
> latter compiler must force it as the only available.

Agreed.