On Friday, June 28, 2013 13:55:45 Adam D. Ruppe wrote:
> On Friday, 28 June 2013 at 07:07:39 UTC, Marco Leise wrote:
> > Isn't that what scope is for?
>
> I don't really know. In practice, it does something else (usually
> nothing, but suppresses heap closure allocation on delegates).
> The DIPs relating to it all talk about returning refs from
> functions and I'm not sure if they relate to the built ins or
> not- I don't think it would quite work for what I have in mind.
Per the spec, all scope is supposed to do is prevent references in a parameter
to be escaped. To be specific, it says
-------
references in the parameter cannot be escaped (e.g. assigned to a
global variable)
-------
So, in theory, if you had something like
auto foo(scope int[] i) {...}
it would prevent i or anything refering to it from being returned or assigned
to any variable which will outlive the function call. However, scope currently
does _nothing_ for anything other than delegates - which is why I think that
using the in attribute is such an incredibly bad idea. Using either in or
scope on anything other than delegates could result in all kinds of code
breakage if/when scope is ever implemented for types other than delegates.
For delegates, it has the advantage of telling the compiler that it doesn't
need to allocate a closure (since the delegate won't be used passed the point
when it's calling scope will exist as could occur if the delegate escaped the
function it was passed to), but I'm not sure that even that works 100%
correctly right now.
We really should sort out exactly what we're going to do with scope one of
these days soon.
But the stuff that some of the DIPS do with scope (e.g. returning with scope -
which is completely against the spec at this point) are suggestions and not at
all how it currently works.
- Jonathan M Davis
