associative array: unexpected results after static initialization

[Steven Schveighoffer]

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)
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.

-Steve