[Issue 5279] Function-static associative arrays

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=5279

Dmitry Olshansky  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dmitry.o...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #8 from Dmitry Olshansky  ---
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 ***

--

[Issue 5279] Function-static associative arrays

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=5279


SomeDude lovelyd...@mailmetrash.com changed:

   What|Removed |Added

 CC||lovelyd...@mailmetrash.com


--- Comment #7 from SomeDude lovelyd...@mailmetrash.com 2012-04-27 07:32:41 
PDT ---
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];

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 5279] Function-static associative arrays

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=5279


Jonathan M Davis jmdavisp...@gmx.com changed:

   What|Removed |Added

 CC||jmdavisp...@gmx.com


--- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2010-11-26 15:36:02 
PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 5279] Function-static associative arrays

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=5279



--- Comment #2 from bearophile_h...@eml.cc 2010-11-26 15:44:29 PST ---
(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() {}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 5279] Function-static associative arrays

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=5279



--- Comment #3 from Jonathan M Davis jmdavisp...@gmx.com 2010-11-26 15:49:02 
PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 5279] Function-static associative arrays

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=5279


nfx...@gmail.com changed:

   What|Removed |Added

 CC||nfx...@gmail.com


--- Comment #4 from nfx...@gmail.com 2010-11-26 15:53:05 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 5279] Function-static associative arrays

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=5279



--- Comment #5 from bearophile_h...@eml.cc 2010-11-26 16:37:20 PST ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 5279] Function-static associative arrays

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=5279



--- Comment #6 from Jonathan M Davis jmdavisp...@gmx.com 2010-11-26 17:21:30 
PST ---
@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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---