Getting the const-correctness of Object sorted once and for all

[Era Scarecrow]

On Sunday, 13 May 2012 at 22:51:05 UTC, Jonathan M Davis wrote:
> Walter fully intends to require that opEquals, opCmp, toHash, 
> and toString all be const @safe pure nothrow - on both classes 
> and structs. And the reality of the matter is, if that 
> requirement _isn't_ there on classes, then the usage of any of 
> those functions in @safe, const, pure, or nothrow code is 
> seriously hampered - especially const and pure. This has been 
> discussed quite a bit before, and we're pretty much stuck 
> thanks to transitivity.

  I've been wondering sometimes, if beta builds could be made (but 
not official release builds) that enforce the way it's suppose to 
be, and then we can try to compile against that version and see 
how much difference or how much breaks. The problem may not be 
quite as bad as we think it is. Honestly I don't see why oEquals, 
opCmp and toHash can't be const (as the data shouldn't change). 
toString and toHash may want to cache it's current result 
(perhaps?).