Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Mar 14 22:15:39 PDT 2012


On Wed, Mar 14, 2012 at 11:58:01PM -0500, Andrei Alexandrescu wrote:
> On 3/14/12 6:16 PM, H. S. Teoh wrote:
> >- Declaring an AA with non-const array keys will cause reams and reams
> >   of compile errors. I'm not *too* worried about this at the moment
> >   since it doesn't make sense to have non-const AA keys anyway. I'm
> >   also seriously considering forcing *all* AA keys to be immutable,
> >   in which case this will become a non-issue.
> 
> I think the built-in associative array must allow non-constant keys.
> As long as there's no memory safety issue, the AA should work with
> types that the user doesn't change for comparison purposes but can
> otherwise modify.
> 
> A practical matter is that if we introduce this restriction we'll
> break a ton of code.
[...]

Understood. But if the user changes the keys then the AA will
malfunction. (This is no worse than the current behaviour, I suppose.)

So now I've to track down why non-const keys trigger a ton of errors...
:-/


T

-- 
"No, John.  I want formats that are actually useful, rather than over-featured megaliths that address all questions by piling on ridiculous internal links in forms which are hideously over-complex." -- Simon St. Laurent on xml-dev


More information about the Digitalmars-d mailing list