On Friday, 25 October 2013 at 00:00:36 UTC, Andrei Alexandrescu
wrote:
with (setAllocator!Mallocator)
That'd be a mistake except perhaps in two circumstances:
1) if setAllocator was @system with warnings attached.
or
2) if the content inside the with block was all a pure function.
#1 is obvious, storing a reference to freed memory isn't @safe
nor pretty. But I think #2 is somewhat interesting. A pure
function cannot escape any reference, since it isn't allowed to
access outside mutable data at all. When the pure function
returns, the only possible places one of the other allocated
values could be are in one of its parameters - which are set
right here on the same (or the immediately following) line as the
call to setAllocator, so it is no surprise, or the return value,
and ditto.
Otherwise, by the pure rules, they must all be local and thus
freeing them is fine.
I'm not quite sold on replacing the global allocator. I'd
generally prefer to use a container type so it is clear who the
owner is, and then if anything, just prohibit slice concat (and
preferably, storing them too, scope storage class!!!!111!one) so
you don't accidentally reallocate without informing the owner.
But if we did do it, signatures like
@system AllocatorResetStruct setAllocator(Allocator)() {}
and
@safe void setAllocator(Allocator)(pure @safe void function()
code) {}
just might work out.
