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