Instead, what if the literal syntax was amended to take an optional type name, like this:

   // Defaults to using built-in associative array type
   auto assocArray = [
      "hello" : "world
   ];

   // Uses my own custom type.
   auto hashtable = MyHashTableType!(string, string) [
      "hello" : "world
   ];

You could accomplish that pretty easily, as long as the custom type had a no-arg constructor and a function with the signature:

   void add(K key, V val)

What about this: an associative array literal would have the type (Key, Value)[] (an array of a Key-Value tuple), and you'd use opAssign (or the new implicit casting operators from D2.0, opImplicitCastFrom or what it was) to convert it to your hash table type.

MyHashTableType hashtable = ["hello" : "word"];

expends to

(char[], char[])[] tmp = [("hello", "word")];
MyHashTableType hashtable = tmp;

expands to

(char[], char[])[] tmp = [("hello", "word")];
MyHashTableType!(char[], char[]) hashtable; //magical type inference
hashtable.opAssign([("hello", "word")]);

Anyway, looking forward to the day the D compiler is merely a CTFE interpreter, and the actual code generation is implemented as D library and executed as normal user code during compile time.

Reply via email to