[Issue 8681] dmd accepts mutable AA key types for objects

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=8681

Marco Leise  changed:

   What|Removed |Added

 CC||marco.le...@gmx.de

--- Comment #2 from Marco Leise  ---
(In reply to hsteoh from comment #1)
What works with the type system is to isolate the fields from C that define its
equality:

struct ImmutableCPart
{
int x;

size_t toHash() const {
return typeid(int).getHash(x);
}
bool opEquals(const C c) const {
return x == c.x;
}
}

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

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

C[ImmutableCPart] lookup;

--

[Issue 8681] dmd accepts mutable AA key types for objects

[d-bugmail]

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


hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx


--- Comment #1 from hst...@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: ---