why allocators are not discussed here

Adam D. Ruppe destructionator at gmail.com
Fri Jun 28 10:56:44 PDT 2013


On Friday, 28 June 2013 at 17:43:21 UTC, Jonathan M Davis wrote:
> it would prevent i or anything refering to it from being 
> returned or assigned to any variable which will outlive the
> function call. However,

That's fairly close to what I'd want. But there's two cases I'm 
not sure it would cover:

1:

struct Unique(T) {
    scope T borrow();
}

If the unique pointer decides to let its reference slip, it 
wouldn't want it going somewhere else and escaping, since that 
breaks the unique need.

This is important for a few cases. Here's one:

   int* foo;
   {
      Unique!(int*) bar;
      foo = bar.borrow;

      int* ok = bar.borrow; // this should be ok, because this 
never exists outside the same scope as the Unique
   }

   // foo now talks to a freed *bar, so that shouldn't be allowed

Similarly, if bar were reassigned, this could cause trouble, but 
what we might do is just disallow such reassignments, but maybe 
it could work if it always goes down in scope. I'd have to think 
about that.


(I'm thinking my borrowed thing might have to be a type 
constructor rather than a storage class. Otherwise, you could get 
around it by:

int* bar(scope int* foo) {
   int* b = foo;
   return b;
}

Unless the compiler is very smart about following where it goes.)


But if scope works on the return value too, it might be ok.


maybe 2:

void bar(scope int* foo, int** bar) {
     *bar = foo;
}


Actually, I'm reasonably clear the spec's scope words would work 
for this one. But we'd need to be sure - this is one case where 
pure wouldn't help (pure generally would help, since it disallows 
assignments to the outside world, but there's enough holes that 
you could leak a reference).


To be memory safe, these would all have to be guaranteed.


More information about the Digitalmars-d mailing list