Bug 19239 – Fix unsafe casting away of const in hashOf(const Object)

Status
NEW
Severity
normal
Priority
P3
Component
druntime
Product
D
Version
D2
Platform
All
OS
All
Creation time
2018-09-10T16:15:45Z
Last change time
2024-12-07T13:38:37Z
Assigned to
No Owner
Creator
Nathan S.
Moved to GitHub: dmd#17371 →

Comments

Comment #0 by n8sh.secondary — 2018-09-10T16:15:45Z
`Object.toHash` is not const. Since a struct's `toHash` needs to be const, usually a struct will just cast away const-ness of an Object and hope that this violation of the type system doesn't cause a catastrophe. This happens to be okay for objects that don't override `toHash` because the base implementation is based on the object's address and is logically const even though it doesn't have the `const` attribute. We can make this sound by performing a runtime check to see if it uses the address-based Object.toHash. (It would be even better if we could perform a runtime check to see if its overridden with a const function, but I don't believe that is a way to do this.) Doing this will let us legitimately call `const(Object).toHash()` in `@trusted` code.
Comment #1 by robert.schadek — 2024-12-07T13:38:37Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/17371 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB