std.allocator ready for some abuse

[Namespace]

On Friday, 25 October 2013 at 19:03:14 UTC, Dmitry Olshansky 
wrote:
> 25-Oct-2013 22:41, Namespace пишет:
>> On Friday, 25 October 2013 at 17:57:23 UTC, Dmitry Olshansky 
>> wrote:
>>> 25-Oct-2013 16:52, Jacob Carlborg пишет:
>>>> On 2013-10-25 02:01, Andrei Alexandrescu wrote:
>>>>
>>>>> Oddly enough this can be actually done.
>>>>>
>>>>> with (setAllocator!Mallocator)
>>>>> {
>>>>>   ...
>>>>> }
>>>>>
>>>>> setAllcator returns an rvalue that changes the global 
>>>>> allocator to the
>>>>> Mallocator in the constructor, and restores it to whatever 
>>>>> it was in
>>>>> the
>>>>> destructor.
>>>>
>>>> Wouldn't this be very unsafe? Say you call another function 
>>>> inside the
>>>> with-statement and that function assumes the standard GC for 
>>>> allocating
>>>> memory.
>>>>
>>>
>>> Very true. To put it simply it's a disastrous idea that sadly 
>>> is too
>>> easy to be ignored.
>>>
>>> IMHO we'd better start with containers and refitting Phobos 
>>> from
>>> built-in AA/arrays to user-defined containers. One 
>>> interesting way
>>> there is to accept/adopt containers as OutputRange.
>> Did you mean to get rid of built-in arrays / kill int[] and 
>> replace it
>> with Array!T?
>
> Hm, arrays? Kill? No, they are incredibly nice for prototyping 
> + they are very useful even as just slices.
>
> What I mean is to make it easy to use Phobos stuff with other 
> containers in place of built-ins, basically no hard-codding 
> behind the scenes.
>
> Typical offender is Appender - it's rigid, has dangerous API 
> and doesn't support building anything but T[]. For this 
> particular case see: 
> http://d.puremagic.com/issues/show_bug.cgi?id=11138
>
> Another one:
> http://dlang.org/phobos/std_array.html#.array
> It's trivially expendable to any other Array-like type, yet ATM 
> it's hardwired.
>
> O.T. I'd gladly kill built-in AA though just to save people a 
> lot of time spent on debugging that crap. More precisely I'd 
> keep AA _literals_ and give the user the means to construct any 
> type of Key-->Value store out of it. It's too late probably.

With which syntax? As far as e.g. int[string] (and not something 
ugly as Map!(string, int)) would stay what would be the problem 
to change the backend?