digitalmars.D.bugs - [Issue 8681] New: dmd accepts mutable AA key types for objects
- 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
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: -------
Sep 17 2012
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: -------
Jul 08 2013