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