DIP69 - Implement scope for escape proof references

[Walter Bright via Digitalmars-d]

On 12/12/2014 4:19 AM, Manu via Digitalmars-d wrote:
>> I simply do not understand why distinguishing beteen ref and not-ref is a
>> cornerstone of everything you do.
>
> I've said so many times, it's the single greatest regular frustration
> I encounter, by far.
> That is of course a relative measure. It's not the 'cornerstone of
> everything I do'; I don't start discussions about things that are not
> broken and otherwise painless.
> It is the thing that is *the most broken*, and leads to the most edge
> cases, general bloat, and text mixins.
> It comes up the most frequently, and by that metric alone, I consider
> it highest priority on my list.
>
> I've also said many times before, it possibly stems from the fact that
> one of the key cornerstones of almost everything I do in D is interact
> with other languages.
> This is a practical reality, I can't write all my code in D, and have
> mountains of existing code to interact with.
> Boilerplate is the result. D has powerful systems to automate
> boilerplate, like a carrot dangling right in front of my face, but
> it's almost always thwarted by ref, and almost exclusively so.
>
> My recent work updating LuaD to support all the features I required
> wasted about 80% of my time dealing with ref issues.
> In my past C++ bindings solutions, much code, which was otherwise
> simple, readable, and elegant, turned into a mess of text mixins,
> almost exclusively because ref is broken.

You've said this before, many times, but what is lacking is an explanation of 
WHY. What is the pattern, and why do you need that pattern? You say you don't 
like auto ref because it doesn't give you exact control, but what are the cases 
where auto ref is wrong?


>> Consider a ref counted type, RC!T. If scope were transitive, then you could
>> not have, say, a tree where the edges were RC!T. I.e., the payload of an RC
>> type should not be forced to be scope.
>
> I'm not sure I quite visualise this correctly...

struct Tree {
    RefCount!(Tree*) left;
    RefCount!(Tree*) right;
    ...
}


> So you're saying that a pointer itself shouldn't be able to escape a
> call tree, but the thing it points to should be able to escape just
> fine?

Yes.


> It feels like that kinda defeats the purpose...

You're arguing that a data structure with only one access point is the only kind 
of data structure in use. With transitive scope, such a data structure would be 
the only one possible!


> I guess you're seeing a situation where 'scope' is almost exclusively
> useful as a mechanism to tell the RC that it doesn't need to worry
> about ref-fiddling, and the thing we're passing isn't interested in
> scope restrictions at any level other than that RC optimisation?
> I guess I can see your angle... but my reaction is if that's all you
> are concerned about, maybe scope is the wrong tool for eliding ref
> fiddling in that case :/

'scope' is a way to say that this use of a pointer does not escape this scope. 
That is incredibly useful.

Recall my statements that pervasive refcounting is a terrible performance 
problem because of all the inc/dec? Knowing that references cannot escape means 
an inc/dec pair can be elided.