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

           Summary: immutable class variable not properly initialized when
                    the constructor initializing it is non-shared
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: jmdavisProg@gmx.com


--- Comment #0 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-06-05 23:31:52 PDT ---
This is related to bug# 6113. If you go into std.datetime and change the static constructors which initialize UTC._utc or LocalTime._localTime (search for "_utc =" or "_localTime =" - minus the quotes - to find them quickly), then this code will fail:

import std.datetime;

shared static this()
{
  assert(UTC() !is null);
  assert(LocalTime() !is null);
}

void main()
{}


As long as those static constructors are shared, then this code is fine. But if they're not shared, then the assertions fail. I believe that this is related to bug# 4923 and the fact that immutable global variables and immutable static variables are implicitly shared. I really think that the language should be altered such that it be an error to attempt to initialize an immutable global variable or immutable static variable in a non-shared constructor. Since, they're implicitly shared, it doesn't make sense to initialize them in a thread-local manner anyway. And it's obviously causing problems as-is.

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

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


Brad Roberts <braddr@puremagic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |braddr@puremagic.com


--- Comment #1 from Brad Roberts <braddr@puremagic.com> 2011-06-06 00:21:37 PDT ---
While you've framed this as related to immutable (and I agree with your assessment), there's a broader problem of the definition of order of initialization.  For the main thread, is it one or two passes?

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

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


Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com


--- Comment #2 from Steven Schveighoffer <schveiguy@yahoo.com> 2011-06-08 10:41:02 PDT ---
I agree with Jonathan, immutables should not be assignable in non-shared ctors.

The runtime works like this:

1. program startup
2. run all shared static ctors
3. run all thread-local static ctors
4. run application
   4a. on thread creation, run all thread-local static ctors
   4b. on thread destruction, run all thread-local static dtors
5. run all thread-local static dtors
6. run all shared static dtors.
7. end program

So everything is unraveled the same way it was, um... raveled :)

I think since immutable means 'store globally', it should be only assignable from a shared ctor.  Otherwise, you run into issues.

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