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

           Summary: dmd accepts mutable AA key types for objects
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: jmdavisProg@gmx.com


--- Comment #0 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-09-17 13:29:18 PDT ---
I would have thought that this would have been reported already, but I can't find it, so I'm reporting it. AA keys are supposed to be required to be immutable, but the compiler is not correctly enforcing that. For instance, take this code:

void main()
{
    class C
    {
        int id = 42;
    }

    C c = new C;
    int[C] cArr;

    cArr[new C] = 42; //should not compile. new C is not immutable.
    cArr[c] = 23; //should not compile. c is not immutable.

    C value = cArr.keys[0]; //should not compile. keys[0] should be immutable.
    ++value.id;

    struct S
    {
        int id = 12;
    }

    S* s = new S;
    int[S*] sArr;

    sArr[new S] = 7; //should not compile. new S is not immutable.
    sArr[s] = 3; //should not compile. s is not immutable.

    int[char[]] strArr;
    char[] str = "g".dup;
    strArr[str] = 7; //Correctly fails to compile.
}


Every single insertion into AA in that could should fail to compile, but only the char[] one does. Clearly, dmd is not properly checking for immutability with objects. It may be that the AA implementation rewrite which is currently being worked on will need to be completed for this to be properly fixed, but the longer that it stays like this, the more code that will break once it's fixed. And it _needs_ to be fixed, because otherwise there are going to be all kinds of problems with AA keys being changed after they've been used to insert values into an AA.

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


hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx


--- Comment #1 from hsteoh@quickfur.ath.cx 2013-07-08 20:10:39 PDT ---
There's a case where accepting mutable keys may be OK:

class C {
    immutable int x;
    int y, z;

    this() { ... /* initialize x */ }

    size_t toHash() const {
        // The "real" data is in x; y and z are used for, e.g., caching
        // or holding temporary values
        return typeid(int).getHash(x);
    }
    bool opEquals(const C c) const {
        return x == c.x;
    }
}

Since both toHash and opEquals only depend on C.x, it should be permissible to accept mutable C as AA key; the immutability of C.x guarantees we won't run into problems.

The problem is, I don't think such a case is expressible in the current type system.

(Though arguably, such cases are probably bad design and shouldn't be
encouraged/catered to.)

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