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

[Jakob Ovrum]

On Monday, 14 May 2012 at 12:22:30 UTC, Steven Schveighoffer
wrote:
> On Mon, 14 May 2012 02:35:16 -0400, Jakob Ovrum 
> <jakobovrum at gmail.com> wrote:
>>
>> 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.

Yes, but using const for these objects makes no sense because
they all require temporary mutation (the Lua stack) to do
anything meaningful. This includes opEquals and toString. Thus
the option should be there not to use const.

> 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

Right, I think this is the way to go. We have to accommodate both
kind of object.