const(Object)ref is here!

[Steven Schveighoffer]

On Mon, 06 Dec 2010 08:47:33 -0500, Jason House  
<jason.james.house at gmail.com> wrote:

> Jonathan M Davis Wrote:
>
>> On Sunday 05 December 2010 23:59:58 so wrote:
>> > On Mon, 06 Dec 2010 02:51:32 +0200, Michel Fortin
>> >
>> > <michel.fortin at michelf.com> wrote:
>> > > <http://d.puremagic.com/issues/show_bug.cgi?id=5325>
>> >
>> > Great!
>> >
>> > > See the strange predicate for the const(Object) version? That's  
>> because
>> > > opCmp() in Object doesn't work with const.
>> >
>> > For the same reason opEquals acting funny with const?
>>
>> Neither are marked as const on Object itself, and that needs to happen  
>> for
>> Object to be const correct. toHash() and toString() (or writeFrom() or  
>> whatever
>> it's going to become) have the same problem. None of them are const in  
>> Object.
>>
>> - Jonathan M Davis
>
> If object did that, things deriving from Object could not be lazy or  
> memoize. It occurs to me that things deriving from object should be able  
> to use const-correct functions and still compile. I don't have a D  
> compiler handy or I'd see how well dmd handles that. I'd expect changing  
> an input argument from T to const(T) should work since it's expanding  
> the range of valid inputs. Similarly, the method itself should be able  
> to become const since that too is expanding the valid input (to the  
> implicit first argument).

It doesn't work.  obj == obj calls .opEquals(obj, obj), whose signature is:

bool opEquals(Object obj1, Object obj2)

So even if you mark a derived instance's opEquals as const, the derived  
class is stripped back down to Object before any calls are made.

Memoization and lazy calculations are not as important as being able to  
compare const or immutable objects.

-Steve