hashed array?

[Don]

On 14.11.2012 16:39, H. S. Teoh wrote:
> 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.

Yeah, that's from the library point view. From the compiler side, the 
problem is that this is a type which the compiler knows far too much about.
I cannot see any way that the coupling between compiler and library can 
be less than we started with. The compiler has to relinquish control 
over most of the semantics, but cannot get rid of it all.

>
> 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
>