std.allocator ready for some abuse

[Adam D. Ruppe]

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.