std.allocator ready for some abuse

[Namespace]

On Friday, 25 October 2013 at 14:09:55 UTC, Jakob Ovrum wrote:
> 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.
I don't get your problem.

>> And if it is possible to change the allocator for some arrays, 
>> why shouldn't we implement it?
>
> Because it has a significant cost.
Which 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.
The language cannot protect you from every mistake you can do. 
You should know what you do. If you don't, don't use such a 
feature. It's very simple.