[Issue 10009] foreach_reverse and AA.byKey/byValue

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10009

--- Comment #22 from yebblies <yebblies at gmail.com> ---
(In reply to Ketmar Dark from comment #21)
> (In reply to yebblies from comment #20)
> > Anyone looking for high performance in the built-in AAs is on the wrong track.
> but why? 

Because AAs can be optimized for different usage patterns, but builtin AAs
cannot.  I'm not saying we shouldn't care at all about their performance, just
that usability is more important concern as their performance is less likely to
be critical.

> it's wrong to assume that AA has any defined order of items for
> iteration. this is *really* wrong.

Yes, it's wrong, but it's convenient.  Deterministic behavior is always nice to
have.

> but there is nothing wrong with fast and
> memory-effective built-in AAs. why include language feature that is known to
> be slow when it can be reasonably fast?

It's a trade-off.

> built-in AAs are very handy. and if they known to be slow, people will start
> to roll their own AA implementations virtually each time they want to use
> AA. and then we can just kill built-in AAs altogether.

People rolling their own specialized AAs into phobos would be a great thing. 
Slightly slower AAs would be just fine for scripting and prototyping.

> i believe that built-in AAs should be fast, but not necessarily featurefull.
> and AAs with more features can be implemented in Phobos.

With hindsight, I don't think AAs belong in a language as powerful as D.  They
should be done in the library.  The dedicated syntax is nice, but minor.

> > > yet i'm not sure that everyone are ready to pay 8/64 bytes per AA element
> > > for this feature.
> > Maybe not.
> i certainly don't want that overhead. i done some work on faster byKey.first
> though, see https://issues.dlang.org/show_bug.cgi?id=13410

Yeah, that's a similar tradeoff.

--