Bruno Medeiros wrote:
> Walter Bright wrote:
>> Sports associative array literals, and struct literals. This enables compile time function execution to work with symbol tables (AA's) and user defined types.
>>
>> http://www.digitalmars.com/d/changelog.html
>>
>> http://ftp.digitalmars.com/dmd.1.014.zip
> 
> "If any of the keys or values in the KeyValuePairs are an ExpressionTuple, then the elements of the ExpressionTuple are inserted as arguments in place of the tuple. "
> 
> Can you give an example of that? I was thinking of something like:
>   int[char[]] f;
>   f = [ Tuple!(["one"[]:1, "two":2]) ];
> but it didn't work.

I hadn't tried yet, but I just did:
---
import std.stdio;

template Tuple(Ts...) { alias Ts Tuple; }

void main() {
    // This is pretty cool:
    writefln([Tuple!(4,5,6) : Tuple!(-1,-2,-3)]);
    // outputs: [4:-1,5:-2,6:-3]

    // But it doesn't seem to care if the numbers of keys and values
    // go out-of-sync: (I wonder if this is a bug)
    writefln([1 : Tuple!(100, 200, 300), 111 : 222, Tuple!(2,3,4) : -400]);
    // outputs: [1:100,2:300,3:222,4:-400,111:200]

    // And the number of keys must match the number of values
    //writefln([1 : Tuple!(1,2)]);
    // Compile-time error:
    // "Error: number of keys is 1, must match number of values 2"
}
---

Like it says in the comment, I wonder if the behavior of the second one is a bug...

Frits van Bommel wrote:
> Like it says in the comment, I wonder if the behavior of the second one is a bug...

It isn't a bug, though I'm not sure what utility it has.

Walter Bright wrote:
> Frits van Bommel wrote:
>> Like it says in the comment, I wonder if the behavior of the second one is a bug...
> 
> It isn't a bug, though I'm not sure what utility it has.

I'd prefer it if it wasn't allowed. It would probably catch accidental-mismatch bugs without reducing the power of the construct. If someone actually *wants* the current behavior, they could use the implicit tuple flattening to put all keys in one tuple and all values in another.

I just don't think that "[A : B, 1 : 2, C : D][1]" should be allowed to be anything other than 2 regardless of what A, B, C and D happen to be (as long as A and C aren't tuples containing the value 1).

Don Clugston wrote:
> BTW, these read-only AAs are great for eliminating case statements!
> ------------------
> char [] a;
> switch(k)
> {
> case 2: a="he"; break;
> case 4: a= "ho"; break;
> case 6: a="hum"; break;
> }
> ------------------
> becomes:
> ------------------
> char [] a = [2:"he"[], 4:"ho", 6:"hum"][k];
> ------------------
> Which is pretty awesome when you have a lot of trivial cases; ought to generate better code, too.

This certainly looks like it could become an idiom! In that case I might suggest another way of writing it:

  char [] a =
  [
    2:"he"[],
    4:"ho",
    6:"hum"
  ]
  [k];

The latter is easier to read, especially when there are a lot of members. Problem with both is still that [k] ends up quite far from the assignment. Of course with a named AA we could write:

char [] a = myReadOnlyAA [k];

Walter Bright wrote:
> Sports associative array literals, and struct literals. This enables compile time function execution to work with symbol tables (AA's) and user defined types.

When you create invariants, will we be able to use associative array literals to instantiate invariant associative arrays? Or do you plan on making associative array literals available to instantiate all associative arrays before then?