DIP69 - Implement scope for escape proof references

[via Digitalmars-d]

On Thursday, 11 December 2014 at 12:48:05 UTC, Manu via 
Digitalmars-d wrote:
> On 8 December 2014 at 07:29, Walter Bright via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On 12/7/2014 6:12 AM, Dicebot wrote:
>>>
>>> But from existing cases it doesn't seem working good enough. 
>>> For example,
>>> not
>>> being able to represent idiom of `scope ref int foo(scope ref 
>>> int x) {
>>> return x;
>>> }` seems very limiting.
>>
>>
>>   scope ref int foo(ref int x);
>>
>> will do it.
>
> Will it? It looks like foo can't be called with scope data?

This is a point that most people don't seem to understand yet, 
and which wasn't obvious for me either, at the beginning:

* A `ref` parameter means that it cannot escape the function, 
_except_ by return.
* A `scope ref` parameter means that it cannot escape the 
function  _ever_, not even by return.
* A `scope ref` return means that it cannot leave the current 
statement.

Therefore, a `scope ref` return value can be passed on to the 
next function as a `ref` argument. If that function again returns 
a reference (even if not explicitly designated as `scope`), the 
compiler will treat it as if it were `scope ref`.

> I'm also quite uneasy with the fact that scope would not be 
> transitive
> as a storage class. What happens when it's applied to a value 
> type,
> like a struct, that contains some pointers? An adaptation 
> wrapper for
> a single pointer is super common; ie, a tiny struct passed by 
> value
> with scope needs to have it's contained pointer receive the 
> scope-ness
> of the argument.

I agree, this is important. In my proposal, this works without 
transitivity. The wrapper stores the pointer as a `scope` member, 
then by copying the wrapper, the pointer gets copied implicitly, 
to which the normal scope restrictions apply (`scope` on members 
means "will not outlive the aggregate"). If it stored it as 
normal non-scope pointer, it couldn't get assigned in the first 
place. (Additionally, some higher level tricks are possible if we 
allow scope for value types and overloading on scope.)