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

           Summary: `immutable pure` constructors must not be allowed for
                    mutable construction
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: accepts-invalid, spec
          Severity: critical
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: verylonglogin.reg@gmail.com


--- Comment #0 from Denis Shelomovskij <verylonglogin.reg@gmail.com> 2013-06-16 00:54:04 MSD ---
As `pure` functions can access `immutable` static data `immutable pure` constructors must not be allowed for mutable construction.

So this code must be rejected:
---
immutable int i;

class C
{
    int* p;

    this() immutable pure
    { p = &i; }

}
void main()
{
    ++*new C().p; // changes `i`
}
---

Current behaviour is already documented (dlang.org pull #317) so specs have to
be changed too.

-- 
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=10368


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com


--- Comment #1 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-06-15 14:53:13 PDT ---
It's fine as long as the constructor is strongly pure, but as the example shows, weak purity isn't enough.

-- 
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=10368



--- Comment #2 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-06-15 14:59:55 PDT ---
Actually, I take that back. The constructor here _is_ strongly pure. The problem is not strong vs weak. The problem is that the compiler must guarantee that nothing outside of the function ends up in the constructed object (or the return value if we were dealing with a function returning a new object rather than a constructor). And in _most_ cases, strong purity is enough for that (and weak purity is often enough if the constructor's body is examined appropriately), but the example shows how it's possible for a strongly pure function to inadvertently cast away immutability on something which it doens't own thanks to the fact that normally having pure functions access statics or globals which are immutable isn't a problem.

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