Bug 6238 – Cannot define global immutable AA

I *believe* this bug has been discussed and reported before, but a search didn't turn up anything. This code fails to compile: immutable test = // auto, const, etc.. also fail [ 'a' : 1, 'b' : 2, ]; void main() { } On 2.053 we get: main.d(2): Error: non-constant expression ['a':1,'b':2] A workaround is to do: enum test = [ 'a' : 1, 'b' : 2, ]; void main() { auto localTest = test; // Use either test or localTest } But of course that will cause test to be copied each time it is referenced (which, besides all the drama in issue 4397 I believe to be correct). The reason this matters is because of CTFE. If I have an AA which I want to be able to use in CTFE and at runtime without causing copies to be made at runtime I'd have to use an immutable AA.

It gets worse. The following doesn't compile either: // (package scope) auto hash = [ "abc":1, "def":2, "ghi":3 ]; Neither does this compile: int[string] hash = [ "abc":1, "def":2, "ghi":3 ]; This happens on both dmd 2.057 (Linux) and gdc 4.6.2 (Linux). It seems that initializing associative arrays with literals only works in function scope. IMHO this is a major bug. It completely breaks CTFE for associative arrays (trying to assign to an assoc array in a CTFE function triggers the same error), and greatly limits the usefulness of having a literal in the first place.

> It completely breaks CTFE for > associative arrays (trying to assign to an assoc array in a CTFE function > triggers the same error) Can you please give an example of this? As far as I know AAs are usable in ctfe.

int[string] initHash(in string[] words) { int[string] h; for (auto i=0; i < words.length; i++) { h[words[i]] = i; // Compiler points to this line and says: Error: non-constant expression ["abc":0,"def":1,"ghi":2] } return h; } int[string] hash3 = initHash(["abc", "def", "ghi"]); Or is this a case of the compiler trying to be helpful and giving a misleading error message? (I.e. the error is supposed to be on the line that initializes hash3, but the compiler is pointing to the cause of the supposed non-constancy of the value.) I tried changing initHash() to construct a hash literal as a string and using mixin() to initialize hash3, but that didn't work either.

Yes, it's a line number bug. The AA works perfectly well in ctfe, but once evaluated it becomes: int[string] hash3 = ["abc":0,"def":1,"ghi":2]; The wrong line is because that was the line it was last modified at, and the interpreter forgets to correct it. The error message is because of the same bug, and occurs after ctfe has finished. Doing everything except trying to initialize a global should be working in ctfe. I've opened a new bug report for the line number bug: issue 7434

*** This issue has been marked as a duplicate of issue 1578 ***