std.allocator ready for some abuse

[Maxim Fomin]

On Friday, 25 October 2013 at 09:13:45 UTC, Namespace wrote:
>>> 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?

Probably because there may be exception thrown between appending 
to arr and end of block. In this particular case compiler may be 
smart enough to optimize it away, but dmd optimization 
capabilities and nothrow is a separate story.