Initialization of the Associative arrays

[Bill Baxter]

BCS wrote:
> Reply to Stewart,
> 
>> "Don" <nospam at nospam.com.au> wrote in message
>> news:g5fmrg$e7o$1 at digitalmars.com...
>>
>>> baleog wrote:
>>>
>>>> Hello,
>>>>
>>>> Is it a bug that i can't do like this:
>>>> int[string] x = ["11":11, "1":1];
>> <snip>
>>
>>> No. You need to tell the compiler that you're using dynamic, not
>>> static arrays. Just add [] after the first entry.
>>>
>>> int[string] x = ["11"[]:11, "1":1];
>>>
>> If it isn't a bug, it's certainly a design silliness:
>> - that array literals take their type from the first element, rather
>> than
>> the lowest common denominator
>> - that there aren't static initialisers for AAs as there are for LAs
>> Stewart.
>>
> 
> I think much of this might come from the need to be able to eyeball 
> parse the code
> 
> auto a = [ .... 16 different function calls ...];// what is the type of a?

Who cares what the type is as long as it's sufficient to hold the 
results of all those function calls?  If you cared you wouldn't have 
been using auto there.

> I think as long as the type of an array literal isn't from the type of 
> the assigned the current solution is about as good as it will get.

Polysemous vals may help here if they ever materialize.

Its not a huge issue in the grand scheme of things, but still feels 
slightly sub-optimal currently.  NumPy arrays use the rule "array type 
is the minimal type that can hold all elements" and it seems to work out 
very well in practice.  Seems to be the path of least surprise for this 
problem.

--bb