std.allocator ready for some abuse

[Namespace]

On Friday, 25 October 2013 at 08:50:23 UTC, Maxim Fomin wrote:
> On Friday, 25 October 2013 at 08:27:52 UTC, Namespace wrote:
>>
>> Something like that: 
>> http://forum.dlang.org/thread/l4btsk$5u8$1@digitalmars.com?page=3#post-pfoxyfzyjxqcqwnvgnpi:40forum.dlang.org
>>
>> Every array has an internal allocator property which can be 
>> reset:
>> ----
>> int[] arr;
>> arr.allocator = Mallocator;
>> ----
>>
>> or
>>
>> ----
>> int[] arr;
>> arr.useAllocator(Mallocator);
>> ----
>
> That's doable.
>
>> But maybe a design without some alias notation would be more 
>> preferable:
>> ----
>> {
>>    ScopeAllocator m;
>>    int[] arr;
>>    arr.useAllocator(m);
>>
>>    arr ~= 42; /// Use m.allocate
>> } /// end of scope: ScopeAllocator collects all remaining 
>> memory.
>> ----
>>
>> And:
>> ----
>> int[] arr;
>> assert(arr is null);
>> {
>>    ScopeAllocator m;
>>    arr.useAllocator(m);
>>
>>    arr ~= 42; /// Use m.allocate
>> } /// end of scope: ScopeAllocator collects all remaining 
>> memory.
>> assert(arr is null);
>> ----
>
> That's also doable. TypeInfo will be bloated more and there 
> would be cost of some sort of scope exit, and, ideally, a check 
> that reference does not escape, but this is doable.

Why the cost of scope(exit)? If ScopeAllocator m get out of 
scope, the DTor is called and ideally the collect method is 
called. That's all. Or am I wrong?