Bug 5279 – Function-static associative arrays

I'd like DMD to support the definition of static associative arrays, that become initialized only once at module start: void foo() { static string[string] map1 = ["bar" : "spam"]; static const string[string] map2 = ["bar" : "spam"]; static immutable string[string] map3 = ["bar" : "spam"]; } void main() {} That is similar to a static this() initialization of those maps, but with visibility limited to foo(). -------------------------- Just for reference this is how DMD 2.050 compiles various kinds of AAs literals, in all cases but fifth_function() the AA seems created again at each function call (I think there is already a bug report about the enum AAs, but I don't remember its number, please add it below if you remember it): string first_function(string k) { immutable string[string] map1 = ["bar" : "spam"]; return map1[k]; } string second_function(string k) { const string[string] map2 = ["bar" : "spam"]; return map2[k]; } string third_function(string k) { enum string[string] map3 = ["bar" : "spam"]; return map3[k]; } string fourth_function(string k) { static enum string[string] map4 = ["bar" : "spam"]; return map4[k]; } immutable string[string] map5; static this() { map5 = ["bar" : "spam"]; } string fifth_function(string k) { return map5[k]; } void main() {} Compiled with: DMD 2.050, -O -release -inline _D5test314first_functionFAyaZAya comdat L0: push EAX mov EAX,offset FLAT:_D11TypeInfo_Aa6__initZ mov ECX,offset FLAT:_D16TypeInfo_HAyayAa6__initZ push dword ptr 0Ch[ESP] push dword ptr 0Ch[ESP] push 8 push EAX push dword ptr FLAT:_DATA[01Ch] push dword ptr FLAT:_DATA[018h] push dword ptr FLAT:_DATA[0Ch] push dword ptr FLAT:_DATA[08h] push 1 push ECX call near ptr __d_assocarrayliteralT add ESP,018h push EAX call near ptr __aaGetRvalue mov EDX,4[EAX] mov EAX,[EAX] add ESP,014h pop ECX ret 8 _D5test315second_functionFAyaZAya comdat L0: push EAX mov EAX,offset FLAT:_D11TypeInfo_Aa6__initZ mov ECX,offset FLAT:_D17TypeInfo_HAyaxAya6__initZ push dword ptr 0Ch[ESP] push dword ptr 0Ch[ESP] push 8 push EAX push dword ptr FLAT:_DATA[01Ch] push dword ptr FLAT:_DATA[018h] push dword ptr FLAT:_DATA[0Ch] push dword ptr FLAT:_DATA[08h] push 1 push ECX call near ptr __d_assocarrayliteralT add ESP,018h push EAX call near ptr __aaGetRvalue mov EDX,4[EAX] mov EAX,[EAX] add ESP,014h pop ECX ret 8 _D5test314third_functionFAyaZAya comdat L0: push EAX mov EAX,offset FLAT:_D11TypeInfo_Aa6__initZ mov ECX,offset FLAT:_D16TypeInfo_HAyaAya6__initZ push dword ptr 0Ch[ESP] push dword ptr 0Ch[ESP] push 8 push EAX push dword ptr FLAT:_DATA[01Ch] push dword ptr FLAT:_DATA[018h] push dword ptr FLAT:_DATA[0Ch] push dword ptr FLAT:_DATA[08h] push 1 push ECX call near ptr __d_assocarrayliteralT add ESP,018h push EAX call near ptr __aaGetRvalue mov EDX,4[EAX] mov EAX,[EAX] add ESP,014h pop ECX ret 8 _D5test315fourth_functionFAyaZAya comdat L0: push EAX mov EAX,offset FLAT:_D11TypeInfo_Aa6__initZ mov ECX,offset FLAT:_D16TypeInfo_HAyaAya6__initZ push dword ptr 0Ch[ESP] push dword ptr 0Ch[ESP] push 8 push EAX push dword ptr FLAT:_DATA[01Ch] push dword ptr FLAT:_DATA[018h] push dword ptr FLAT:_DATA[0Ch] push dword ptr FLAT:_DATA[08h] push 1 push ECX call near ptr __d_assocarrayliteralT add ESP,018h push EAX call near ptr __aaGetRvalue mov EDX,4[EAX] mov EAX,[EAX] add ESP,014h pop ECX ret 8 _D5test314fifth_functionFAyaZAya comdat L0: push EAX mov EAX,offset FLAT:_D11TypeInfo_Aa6__initZ push dword ptr 0Ch[ESP] push dword ptr 0Ch[ESP] push 8 push EAX push dword ptr _D5test34map5yHAyaAa call near ptr __aaGetRvalue mov EDX,4[EAX] mov EAX,[EAX] add ESP,014h pop ECX ret 8

I would expect that this problem would be solved together with however being able to use Objects with CTFE and dynamic memory in general is solved. Since, I believe that it's essentially the same problem that won't allow you to initialize a global variable which is a class type to anything other than null. CTFE can't handle the heap yet. Once it can, AAs should work.

(In reply to comment #1) > I would expect that this problem would be solved together with however being > able to use Objects with CTFE and dynamic memory in general is solved. Since, I > believe that it's essentially the same problem that won't allow you to > initialize a global variable which is a class type to anything other than null. > CTFE can't handle the heap yet. Once it can, AAs should work. In DMD 2.050 this code works, so this enhancement request asks for those foo_map* to be visible inside foo() only: string[string] foo_map1; const string[string] foo_map2; immutable string[string] foo_map3; static this() { foo_map1 = ["bar" : "spam"]; foo_map2 = ["bar" : "spam"]; foo_map3 = ["bar" : "spam"]; } void foo() { // here use foo_map1, foo_map2, foo_map3 } void main() {}

So essentially, you want static local variables to have access to a static constructor like all of the other variables with global lifetime do. Given that that breaks the scoping rules, I'm not sure that it's exactly a good idea. Perhaps allowing for a static constructor which is a nested function? That seems a bit like overkill, but it could theoretically work. If CTFE were properly advanced though, I don't think that it would be an issue. You'd either assign the variable an AA literal, or you'd write a function which created one and returned it, and you'd initialize the variable with that.

Wouldn't that lead exactly to the same race condition prone crap C++ is doing when it comes to initialization of static variables inside functions? Just say no. Immutable data (or de-facto immutable data only accessible through const) is another story, though. (In reply to comment #1) > I would expect that this problem would be solved together with however being > able to use Objects with CTFE and dynamic memory in general is solved. Since, I > believe that it's essentially the same problem that won't allow you to > initialize a global variable which is a class type to anything other than null. > CTFE can't handle the heap yet. Once it can, AAs should work. It's not that easy. The AA has to be allocated in the heap (to deal with later write accesses to the AA). How can CTFE allocate heap memory at the program's runtime? Obviously this doesn't work.

(In reply to comment #3) by Jonathan M Davis: > So essentially, you want static local variables to have access to a static > constructor like all of the other variables with global lifetime do. Given that > that breaks the scoping rules, I'm not sure that it's exactly a good idea. I don't fully understand what you say, but I think you have misunderstood me. Surely I have never asked to break scoping rules. ---------------------- (In reply to comment #4) nfxjfg: > Wouldn't that lead exactly to the same race condition prone crap C++ is doing > when it comes to initialization of static variables inside functions? I don't know. If are sure that happens then please close this enhancement request.

@nfxjfg It's going to have to be able to do it for objects eventually. Yes, it's a thorny problem, but it _can_ be done. The fact that it's a thorny problem is the reason why it hasn't been done _yet_, but it will be done eventually. @Bearophile What I gathered what you were saying is that you were looking for a way to have a static constructor initialize static local variables. Doing that would break scoping rules. However, re-reading your initial comment, it looks like what you want to have happen is for the compiler to effectively set up a static constructor within the function automatically which is not visible to the programmer. The compiler would simply be smart enough to know that static string[string] map1 = ["bar" : "spam"]; translates to something like static string[string] map1; static this() { string[string] map1_temp; map1_temp["bar"] = "spam"; map1 = map1_temp; } That's not an entirely bad idea, but it seems to me that since CTFE has to be fixed to be able to handle this situation anyway, we might as well just fix CTFE rather than have the compiler special case this situation.

The following program doesn't compile with 2.059: import std.stdio, std.container, std.range; string[char] aa = ['f':"foo", 'b':"bar"]; void main(){ foreach (ch, str; aa) { writefln("[%s]: [%s]", ch, str); } } It gives: PS E:\DigitalMars\dmd2\samples> rdmd -O -inline bug.d bug.d(3): Error: non-constant expression ['f':"foo",'b':"bar"] PS E:\DigitalMars\dmd2\samples> This also happens with the following: const string[char] aa = ['f': "foo",'b': "bar"]; static const string[char] aa = ['f': "foo",'b': "bar"]; immutable string[char] aa = ['f': "foo",'b': "bar"]; static immutable string[char] aa = ['f': "foo",'b': "bar"]; Only this compiles: enum string[char] aa = ['f': "foo",'b': "bar"];

There is already an enhancement for AAs to be initializable at global scope, including const/immutable. *** This issue has been marked as a duplicate of issue 1578 ***