Why does Object.opEquals return int

[Bill Baxter]

Bruno Medeiros wrote:
> Stewart Gordon wrote:
> 
>> Anders F Björklund wrote:
>>
>>> Kristian Kilpi wrote:
>>>
>>>> So the original question remains: why 'opEquals' returns int?
>>>
>>>
>>> Walter says it is for performance reason, when e.g. sorting...
>>>
>>> http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html
>>
>>
>> I'm still not convinced that there's any way that opEquals can be made 
>> more efficient by returning int instead of bool.
>>
>> Stewart.
>>
> 
> Even more so due to the SETE instruction (which gcc uses) and makes 
> converting to a bool after a comparison just as fast as getting an int. 
> I wish Walter would comment on that, because, in the point that the 
> discussion was left using a bool would be just as fast as an int, and I 
> would like a lot of those functions like opEquals to return a bool.

I think it was already pointed out that instruction count doesn't tell 
you anything cycle counts.  SETE maybe one instruction, but that doesn't 
necessarily mean it's any faster.  I may be.  I don't know.  Just it 
isn't a given.  Also I you're free to make your own classes return bool 
from opCmp, it's just Object opCmp that returns int.  And note that it's 
only for _value_ comparison of objects.

Personally I think Object.opCmp returning int is an oddity, but it pales 
in comparison with the mixins/imports problem, the ambiguity of auto, 
and the major bugs left in variadic templates.

--bb