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