std.allocator ready for some abuse

[Namespace]

On Friday, 25 October 2013 at 11:21:55 UTC, Jakob Ovrum wrote:
> 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?

Because Array!int looks a lot more ugly than such a nice thing as 
int[]. And if it is possible to change the allocator for some 
arrays, why shouldn't we implement it?
The default allocator would stay the GC allocator. So if you 
don't want to swap the allocator of your arrays, don't do it.