https://issues.dlang.org/show_bug.cgi?id=2504: reserve for associative arrays

[Jonathan M Davis via Digitalmars-d]

On Tuesday, November 01, 2016 23:36:42 Andrei Alexandrescu via Digitalmars-d 
wrote:
> Please share your thoughts.

Hasn't Martin been working on a new, templatized AA implementation to
replace the current one? As I recall, he said something about postponing it
by a release to focus on something else (helping Walter with @safe issues
IIRC), but it sounded like it was close to ready. And if that's the case, I
really don't think that it makes sense to be doing anything major with the
current implementation.

But regardless of that, I think that the focus of the built-in AAs should be
to have something simple that works. It should be reasonably performant, but
anything involving performance tuning really should be in library type.
We've had quite a few problems with the built-in AAs over the years
(especially with stuff like user-defined key types - in part because it uses
void* internally IIRC), and while the new implementation will hopefully be
much better in that regard, I think that based on the issues with had with
the built-in AAs historically, doing anything that would make them more
complicated should be approached with extreme caution.

And anyone who really wants to do performance tuning is going to need better
facilities than we're going to be able to reasonably provide in the built-in
AAs anyway.

The only real downside to user-defined hash tables at this point is that you
can't use AA literals with them (which we should probably create a DIP for
at some point). Aside from that, there's no reason that a library AA can't
work as well or better than the built-in AAs, and it would be much easier to
have facilities for tuning performance with a library type than with
something built into the language.

I think that effort put towards containers would be much better served
working towards the std.container rewrite (though you would know where that
stands better than the rest of us as well as whether it makes any sense for
anyone to help you right now). Or maybe Martin could use some help in
finishing whatever he's done with the new, built-in AA implementation. I
don't know. But considering that adding reserve to the built-in AAs is not a
small task and that it'is debatable that it should be done at all, there
pretty much has to be something better for Alex to work on.

- Jonathan M Davis