std.allocator ready for some abuse

[Jakob Ovrum]

On Friday, 25 October 2013 at 10:02:08 UTC, Namespace wrote:
> On Friday, 25 October 2013 at 09:51:40 UTC, Maxim Fomin wrote:
>> On Friday, 25 October 2013 at 09:37:23 UTC, Namespace wrote:
>>>
>>> We would have then the possibility to manage our memory by 
>>> ourself. One of D's promises is, that the GC can be disabled. 
>>> Yes, it can, but then we have many many things which do not 
>>> work. For example built-in arrays.
>>
>> Not only arrays, but classes, throwables, scope exits, new 
>> operator, nested structs, etc.
>
> Thats right.
> But I often use temporary arrays, but I still don't like them 
> because they are always consume so much GC memory. But with 
> allocators that would end.
> Let us hope that Walter has the right intention and that Andrei 
> design the allocators for this purpose.

Why does it have to be the opaque druntime dynamic array? Why 
can't you use the hypothetical (planned, rather) 
std.container.Array that supports custom allocators, or a type of 
your own design?

Garbage collected memory management is the only memory management 
paradigm that supports the infinite lifetime model (GC includes 
automatic reference counting). Swapping it out for a different 
memory management technique while libraries or parts of the 
program still rely on infinite lifetime for parts such as the 
slice concatenation operators and closures is disastrous.

The best strategy for avoiding the global GC is to not use the 
language features associated with infinite lifetime, which 
includes slice concatenation and the `new` operator. For implicit 
allocations like closures, we don't have much of a choice, so 
here the capability is useful, but for slice operators? Just use 
a different type!

Currently the `new` operator has capabilities that function calls 
cannot replicate - namely non-static nested class construction 
and construction of classes with non-public constructors - but 
these issues have to be solved anyway to support allocators in 
general.