Bug 2732 – Setting new key for Associative Array of Static Array causes RangeError

string[2][string] hash; // All assignment expressions listed below are compiled without any error nor warning // and throw runtime RangeError. hash["key"] = ["a","b"]; hash["key"] = new string[2]; hash["key"] = null; hash["key"] = ""; hash["key"] = [0,0]; hash["key"][0] = ""; assert(typeid(typeof(hash["key"])) == typeid(typeof(["a","b"])) ); On the other hand, Associative Array of Dynamic Array works well. string[][string] hash; hash["key"] = ["a", "b"]; writefln( hash["key"] ); occurs in both D1/D2.

Simplified test case: int[1][int] hash = null; int[1] v = [1]; //*(hash[0]) = 42; hash[0] = v; Uncomment the commented line, and it works. It looks to me as if |hash[0] = var;| isn't being treated as an initialization of the key, for some reason. -[Unknown]

(In reply to comment #1) real[2][int] hash = null; real[2] v = [3,4]; *(hash[0])=1; write(hash[0]); // -> [1 0], very strange result. where does 0 come from? *1 hash[0]=v; write(hash[0]); // -> [3 4], it works well if key have been already set. *1 real.init is NaN. actually: write(new real[2]) -> [nan nan]. This test code might show us a different bug of accepts-invalid. To make matters worse, following code is compiled without any error and cause runtime object.Exception: lengths don't match for array copy. real[1] v = [3,4]; I think that this code should be an compile-time error because the compiler knows types of both `real[1] v' and `[3,4]'. I will report these bugs if they have not been reported on this tracking system.

This works in D2.053, but still throws a RangeError in D1.

Closing as D1 is retired.