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

[Steven Schveighoffer]

On Mon, 14 May 2012 02:35:16 -0400, Jakob Ovrum <jakobovrum at gmail.com>  
wrote:

> On Sunday, 13 May 2012 at 17:02:46 UTC, Stewart Gordon wrote:
>> On 13/05/2012 17:41, Alex Rønne Petersen wrote:
>> <snip>
>>> I agree with everything but toString(). I'm afraid that forcing  
>>> toString() to be const
>>> will have harm flexibility severely. Can't we do better, somehow?
>>
>> How exactly?
>>
>> If you're talking about memoization, it ought to be possible to make  
>> use of std.functional.memoize to implement it.
>>
>> Otherwise, using toString to change the state of an object is bending  
>> semantics.  If you want a method to generate a string representation of  
>> an object in a way that might do this, then create your own method to  
>> do it.
>>
>> Stewart.
>
> How about logically constant opEquals, toString etc? Currently, this is  
> perfectly possible by just *not using const*. Logical constancy goes  
> beyond memoization.

This means you cannot compare two const objects.

The issue is, non-const opEquals makes sense on some objects, and const  
opEquals makes sense on others.  However, you must make them all come  
together in Object.opEquals.

I think we already have the hooks to properly compare objects without  
requiring Object.opEquals.

Right now, when two objects are compared, the compiler calls  
object.opEquals (that's little o for object, meaning the module function  
*not* the class method).

So why can't object.opEquals be a template that decides whether to use  
Object.opEquals (which IMO *must be* const) or a derived version?  I don't  
think it's that much of a stretch (not sure if we need a compiler fix for  
this).

-Steve