std.allocator ready for some abuse

[Jakob Ovrum]

On Friday, 25 October 2013 at 12:07:30 UTC, Namespace wrote:
> 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[].

If the template syntax is too ugly then we've really failed at 
designing an extensible development platform. Even so, with type 
inference and aliases, the need to write down involved names is 
all but eliminated (not that I think Array!int is a particularly 
involved name).

Not everything belongs in the core language. Conflating slices 
with garbage collected dynamic arrays is a mistake we have to 
live with, but let's not make the situation even more complicated.

> And if it is possible to change the allocator for some arrays, 
> why shouldn't we implement it?

Because it has a significant cost.

> 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.

That's fine as long as you only use the array locally and don't 
pass it to any code that depends on infinite lifetime semantics. 
It also enables circumvention of SafeD unless some language rules 
are changed.