Blaming the D language

[Jonathan M Davis via Digitalmars-d]

On Friday, October 24, 2014 11:03:11 Jakob Ovrum via Digitalmars-d wrote:
> On Wednesday, 22 October 2014 at 07:42:22 UTC, Jonathan M Davis
>
> via Digitalmars-d wrote:
> > Well, the reality of the matter is that you can't truly clear
> > it safely,
> > though we could definitely get closer. The in operator gives
> > pointer access to
> > the internals, and the byKey and byValue may do the same (not
> > to mention,
> > opApply), and they could be in progress when you try and clear
> > out the AA, so
> > if you cleared it out, all of those would still have to work
> > (or maybe throw
> > an Error in the cases where iteration is going on).
>
> This is already the case because of .remove(). Adding a clear
> method wouldn't introduce any *new* problems.

True. And I'm certainly not against adding a clear function (quite the
opposite in fact). I was just pointingout that it won't work for it to just
free all of the memory at that point (that will still be left up to the GC),
so it's not like it would magically solve all of the complaints (and the
inability to explicitly free the memory seems to be one of the complaints that
sparked this thread in the first place). What it _will_ do, however, is make
it so that it's possible to affect all references to an AA whereas nulling a
reference doesn't do that.

As a side note, it _is_ quite possible to clear out an AA right now; it's just
a royal pain and not particularly efficient. All you have to do is use keys()
to get an array of the keys, and then iterate over them, removing each one
from the AA in turn. And voila, it's been cleared. But it's a pretty
ridiculous way to have to go about it. There really should just be a clear
function that does it for you (and more efficently, since it probably won't
need to allocate an array of the keys to do it and could likely take advantage
of internal implementation details to clear it out more efficiently than
sequential calls to remove will).

- Jonathan M Davis