std.allocator ready for some abuse

[Dmitry Olshansky]

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.

-- 
Dmitry Olshansky