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
