DIP69 - Implement scope for escape proof references

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Mon Dec 8 09:23:37 PST 2014


On 12/8/14 11:27 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm at gmx.net>" 
wrote:
> On Monday, 8 December 2014 at 16:04:42 UTC, Steven Schveighoffer wrote:
>> On 12/8/14 10:45 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
>> <schuetzm at gmx.net>" wrote:
>>> On Monday, 8 December 2014 at 15:12:51 UTC, Steven Schveighoffer wrote:
>>>> I think you should eliminate scope returns then. They are not useful.
>>>> I can't think of a single reason why a newly allocated via GC or
>>>> global reference return should have to be restricted to exist only
>>>> within the statement. Both have infinite lifetimes.
>>>
>>> It's for references to objects that are owned by the function (or object
>>> of which the function is a method). These don't have infinite lifetimes.
>>
>> Why not? An object is allocated on the heap, and has infinite lifetime.
>
> "object" as in "instance of struct" ;-)
>
> And I was referring to objects owned by something with finite lifetime,
> e.g. a container.
>
>      struct Array(T) {
>          scope ref T opIndex(size_t);
>      }
>
>      Array!int container;
>      ref x = container[42];  // no

Why not? x has the same lifetime as container!

This is an incorrect arbitrary decision:

module foo;

Array!int arr;

int *x;

void bar()
{
    x = &arr[0]; // should be ok.
}

A struct's member function has no idea of its lifetime, except what it's 
told.

Now, it would make more sense for this:

ref T opIndex(size_t);
scope ref T opIndex(size_t) scope;

But it's sounding to me (from Walter's other comments) like the latter 
function can't exist, because you can't return scope from scope? And 
furthermore, there's no way to overload based on scope? I'm really not 
liking this whole proposal, it either needs to be explained better, or 
rewritten.

-Steve


More information about the Digitalmars-d mailing list