hashed array?

[H. S. Teoh]

On Wed, Nov 14, 2012 at 10:25:53AM +0100, Don Clugston wrote:
> On 12/11/12 20:42, Jonathan M Davis wrote:
> >On Monday, November 12, 2012 11:36:38 H. S. Teoh wrote:
> >>I contend that the problem with built-in AA's is their
> >>implementation, not the fact that they're built-in.
> >
> >Oh, I agree, but we, as a group, have obviously failed to handle the
> >implementation of the built-in AAs properly, and I think that the
> >indications are definitely that it's harder to get the built-in AAs
> >right that it would be to create a library solution.
> 
> I disagree with that 100%.
> Built-in AAs in D1 work fine (They could use a lot of improvement,
> but there's nothing wrong with the basic approach, it's quite
> simple).

I don't know how AA's worked in D1, but the current codebase does not
handle complex value types correctly. For one thing, it uses bitwise
comparison of *arbitrary types*, as opposed to using opEquals or some
such built-in language capability. This is the source of a good number
of AA bugs.


> It was the idea that they could be seamlessly moved to a library type
> that was an unmitigated disaster.

The problem is with making byKey and byValue return ranges, which is a
Phobos concept. That is the source of the schizophrenic code duplication
in object_.d, which probably hides a subtle bug or two. Basically, it's
the conflict between making AA's built-in, and making them compatible
with a Phobos concept.

Either we make it built-in, and if ranges are required then we add new
functions to aaA.d that return ranges, or we make it library-level code,
which means we move it out of aaA.d and add lowerings in the compiler to
map it to a library type. Trying to straddle the two only leads to
disaster.


> And for some reason, there has been a refusal to roll it back to the
> old method which worked.
> 
> The thing that really really should change is the bizarre 'magic
> null' semantics of AAs.

Agreed.


T

-- 
May you live all the days of your life. -- Jonathan Swift