Blaming the D language

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Wed Oct 22 00:42:07 PDT 2014


On Wednesday, October 22, 2014 06:59:02 Jakob Ovrum via Digitalmars-d wrote:
> On Wednesday, 22 October 2014 at 06:42:06 UTC, Ali Çehreli wrote:
> > On 10/21/2014 11:06 PM, thedeemon wrote:
> >>     A[B] freshCleanAA;
> >>     aa = freshCleanAA;
> >>
> >> (where A[B] denotes the type of aa)
> >> That's it!
> >
> > Alternative:
> >     A[B] aa;
> >     aa = aa.init;
> >
> > Ali
>
> `aa.init` is just `null`, which illustrates the problem better:
>
>      int[string] aa = ["foo": 42];
>      int[string] aaAlias = aa;
>      aa = null;
>      assert("foo" !in aa); // Ostensibly cleared...
>      assert(aaAlias["foo"] == 42); // Until aliasing is introduced.

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). To some extent at least,
the internals would still have to be accessible or risk nasty, potentially
@system things happening (though obviously, if nothing has references to them,
then they're prime for garbage collection). So, I don't know how much of an AA
you can truly clear out, and even once you do, it's going to be need to be
left to the GC to collect it all. But it should certainly be possible to make
it so that further calls to byKey, byValue, the in operater, etc. treat the AA
as empty, even if previous calls which have data in use will need to still
have access to that data.

So, I'm sure that the situation could be improved, but I don't know if it can
be fixed completely. The AA implementation needs a _lot_ of work regardless
though.

- Jonathan M Davis




More information about the Digitalmars-d mailing list