On 12/8/14 11:27 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schue...@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=?=
<schue...@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
