associative array: unexpected results after static initialization

[H. S. Teoh]

On Fri, Dec 01, 2017 at 11:59:08AM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote:
> On 12/1/17 11:23 AM, H. S. Teoh wrote:
> > On Fri, Dec 01, 2017 at 04:06:50PM +0000, kdevel via Digitalmars-d-learn wrote:
> > > On Friday, 1 December 2017 at 00:42:00 UTC, H. S. Teoh wrote:
> > > > Here's the fix:
> > > > 
> > > > 	https://github.com/dlang/druntime/pull/1980
> > > 
> > > And wouldn't it be reasonable to add
> > > 
> > >     assert(aa.values == [ "b" ]);
> > > 
> > > to the unittest?
> > 
> > I did think about adding that, but then I didn't want the unittest
> > to dictate which value should take precedence when there are
> > duplicate keys, since that is currently implementation-dependent.
> > At the very least, it merits further discussion.
> 
> 1. If there is going to be an "implementation defined" ambiguity, then
> nobody should ever use it, and it should be an error. This would mean
> a runtime error, since the keys may be runtime values.
>
> 2. I can think of possible (and questionable) reasons one may put in
> duplicate keys in an AA, like if they are defined separately (i.e. you
> use 2 symbols as keys that are sometimes the same, sometimes
> different, and the result is some defined order)
[...]

There is at least 1 use case in the bugzilla issue that justifies AA
literals with (possibly) duplicated keys:

	https://issues.dlang.org/show_bug.cgi?id=15290#c1

Code snippet:
-------
foreach (i; 0..10)
    foreach (j; 0..10) if (pred2 (i, j))
        foreach (k; 0..10) if (pred3 (i, j, k))
            ... and maybe more ...
        {
            auto set = [i: true, j: true; k: true];
            if (set.length == 3)
            {
                 ... we found distinct i, j, k, ...
            }
        }
-------

In this case, the order doesn't matter.


> 3. I can't think of a reason why anyone would implement the AA filling
> algorithm other than foreach-ing over the keys and values.
> 
> So I would say we should define that the last key/value combo takes
> precedence, and it would be good to ensure that's the case with a
> test.

Sure, but that means a spec update besides the unittest addition.


T

-- 
"The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."