Associative Arrays and Interior Pointers

[dsimcha]

== Quote from Leandro Lucarella (llucax at gmail.com)'s article
> I really like the idea of NO_INTERIOR too. I don't think it's possible to
> be the default because if that is the case you can't have array slices
> and/or pointers to a member of a struct/class. But I think it's great for
> very special cases (specially to implement high performance data
> structures) to be able to instruct the GC to discard interior pointers.

Of course, I don't think any reasonable person thinks it should be the default.
The idea is that it would be an unsafe optimization for people who really know
what they're doing or are really having serious trouble with false pointers.  It
should be thought of kind of like using manual memory management in D.

> > A few questions:
> > 1.  (For Leonardo, especially):  Is the GC likely to get precise enough in the
> > near future that something like this would end up being considered a piece of
cruft?
> I'm sorry, but I finally decided to add concurrency to the current GC. The
> main idea is to reduce (almost vanish) pauses. If is not too hard, and
> time help, I'll try to add some preciseness if it only involves changes in
> the internal runtime, but I honestly don't think I'll have the time.
> I'm talking about finishing my thesis here. When it's finished I think and
> hope to keep working on the D GC...

Ok, cool.  I just wanted to make sure that, if we took the time to put this in,
you weren't likely to come back in 6 months and say "I've made the GC almost
completely precise.  All false pointer stuff is now irrelevant and just a bunch of
cruft."  On the other hand, I certainly wouldn't mind if the GC became more
precise instead.

> > 2.  Other than that, is there any reason this should not go in?
> I don't see any reason, is a backward compatible change.
> > 3.  Sean, if you're seriously thinking of putting this in in the near future, let
> > me know so I can fix that patch, too.  I did it the same way as my other GC patch,
> > with no whitespace, so the line numbers might be screwy here, too.
> I think it would be great to have a centralized place where to put this
> improvements. This is another situation where I think Tango vs. Phobos
> issue is killing D. When I started my work in the thesis I had to decide
> whether to work with Phobos or Tango. I finally decided for Tango, because
> is the only option for LDC and because is way better organized (and more
> receptive to patches). But I hate knowing that my work will be available
> (in the best case) only for people using Tango.
> I hate to see the D "community" fragmented.

You're right, this is unfortunate.  Basically every contribution I've made to D is
D2-oriented and completely irrelevant to D1.