DIP69 - Implement scope for escape proof references

[Walter Bright via Digitalmars-d]

On 12/11/2014 4:13 PM, deadalnix wrote:
> On Thursday, 11 December 2014 at 13:55:55 UTC, Marc Schütz wrote:
>> 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`.
>>
>
> No, it understood. It is simply not useful.

The use case is described in the DIP under the 'Scope Ref' heading.


>> 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.
>
> Wut ? You cante store anything with grear lifetime, including non scope things
> (as they'll have infinite lifetime). Meaning the only thing you know, is that
> thing are possibly scoped.
>
> Meaning you have to assume infinite lifetime with every indirection, which make
> this proposal useless.

It means you'll have to wrap the next level of indirection in a ref counting (or 
equivalent) manner.

The great thing about GC is you can leave everything to the GC. But when 
explicitly managing memory, you have to decide for EVERY pointer who owns it, 
when it can be released, etc. Having a transitive scope is NOT going to resolve 
that for you, it isn't even going to help.