• d-bugmail puremagic.com (52/52) Sep 17 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8681
• d-bugmail puremagic.com (30/30) Jul 08 2013 http://d.puremagic.com/issues/show_bug.cgi?id=8681

d-bugmail puremagic.com writes:

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



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: -------

d-bugmail puremagic.com writes:

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


hsteoh quickfur.ath.cx changed:

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



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: -------