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
