Why are opEquals/opCmp arguments not in or const for Objects?

[Peter Williams]

On Monday, 18 March 2013 at 00:16:17 UTC, Timon Gehr wrote:
> On 03/18/2013 12:19 AM, Peter Williams wrote:
>> The current signatures for opCmp/opEqual mean that code like:
>>
>>
>> bool strictly_ordered(T)(in T[] list) {
>>     for (auto j = 1; j < list.length; j++) {
>>         if (list[j - 1] >= list[j])
>>             return false;
>>     }
>>     return true;
>> }
>>
>> will fail to compile if T is a class because opCmp cannot be 
>> called with
>> a const argument.  This restricts the quality of code that can 
>> be
>> written by limiting legitimate use of in/const arguments to
>> functions/methods.
>>
>> Trying to work around this problem by defining opCmp/opEquals 
>> for the
>> class being used with in or const argument does not work as 
>> they are not
>> recognised as an override of the Object methods.
>>
>
> Yes they are.
>
>> So my question is "Why are the arguments to opEquals and opCmp 
>> (for
>> Objects) not declared in or const?".
>>
>
> Because not all valid implementations can be.

Can't those (rare) implementations just do a non constant cast 
when they cast Object to their desired class?

> They shouldn't be in Object anyway.

Yes, if they could just be declared without overriding the 
problem would go away but whichever solution is chosen existing 
code would need minor changes.

Peter