std.allocator ready for some abuse

[Dmitry Olshansky]

25-Oct-2013 23:26, Namespace пишет:
> On Friday, 25 October 2013 at 19:03:14 UTC, Dmitry Olshansky wrote:
>>
>> 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?

Map!(string,int) is fine actually as I'm no syntax fan anyway.

It's not the problem with "backend" as much as with its state and the 
interface it imposes:

a) It's stuck in between compiler intrinsic and library artifact. Being 
neither it has weaknesses of both (well that's fixable).
b) Interface... I don't even know where to start. But first of all: it's 
a hash table and can't be anything else - see the rehash function. More 
interestingly it escapes pointers ('in' operator) that must stay valid 
until another insert. That's a tough constraint on hash table (HT) 
implementation. Being HT it doesn't expose nor allows to change the 
load-factor.
c) Built-in HTs are one size fits all. Needless to say - it doesn't 
always fit and in particular there are many variations that trade 
insert/remove and/or space-efficiency for faster lookup and vise-versa. 
Also to stay on topic - memory management / deterministic cleanup? 
Trivial in UDT but not in built-ins.
d) AA literals are of no use the moment one stops using built-in HTs 
least one constructs temporary built-in HTs on GC heap. In my opinion if 
that's left as is the AA literal feature doesn't quite pull its weight.

All in all built-in AA are aging badly since D1 days.

-- 
Dmitry Olshansky