www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10368] New: `immutable pure` constructors must not be allowed for mutable construction

reply d-bugmail puremagic.com writes:
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



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`
}
---


be changed too.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 15 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10368


Jonathan M Davis <jmdavisProg gmx.com> changed:

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



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: -------
Jun 15 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10368




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: -------
Jun 15 2013