I tested your code and it seems to work correctly. However, what I find troubling is that I would never have thought of trying this out. This is because those two properties are said to return DELEGATES, according to this page: http://dlang.org/hash-map.html, but it does not seem to be correct. Now, I had a look at those properties' implementation and found out that they, in fact, return ranges, which contradicts documentation :(. I think it is safe to assume that  both byValue and byKey return results in the same order, given that they use the same underlying range struct for popFront() and empty(). Thank you for pointing this out.

Ali Çehreli:

> Here is a quick and dirty implementation that is based on the assumption that byKey and byValue visit the elements in the same order:

I think that currently the D specs do not assert that quality of byKey/byValue. So your code is not portable.

Bye,
bearophile

On 12/07/2012 07:40 AM, Phil Lavoie wrote:

> I tested your code and it seems to work correctly.

As bearophile also pointed out, it is based on an assumption that may be incorrect on obscure system ;) but it is trivial to fix. One way is by storing the original aa and doing a lookup of the value:

    ElementType front() /* const */ @property
    {
        return ElementType(keys.front, aa[keys.front]);
    }

> However, what I find
> troubling is that I would never have thought of trying this out. This is
> because those two properties are said to return DELEGATES, according to
> this page: http://dlang.org/hash-map.html

That is a documentation bug. Please improve it by either using the "Improve this page" button on that page or by filing a bug report at http://d.puremagic.com/issues/enter_bug.cgi

Thank you,
Ali