why allocators are not discussed here

Jonathan M Davis jmdavisProg at gmx.com
Fri Jun 28 10:43:09 PDT 2013


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

-------
ref­er­ences in the pa­ra­me­ter can­not be es­caped (e.g. as­signed to a 
global vari­able)
-------

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


More information about the Digitalmars-d mailing list