int opEquals(Object), and other legacy ints

[kris]

Walter Bright wrote:
> Stewart Gordon wrote:
> 
>> xs0 wrote:
>> <snip>
>>
>>> Well, I'm just guessing, but I think something like
>>>
>>>  > int opEquals(Foo foo)
>>>  > {
>>>  >     return this.bar == foo.bar;
>>>  > }
>>>
>>> is compiled to something like
>>>
>>>> return this.bar-foo.bar; // 1 instruction
>>>
>>>
>>> but if the return type is bool, it becomes
>>>
>>>> return this.bar-foo.bar?1:0; // 3 instructions
>>
>>
>> If it does this, then there's a serious bug in the compiler.
> 
> 
> What instruction sequence do expect to be generated for it?
> 
>> Moreover, what's your evidence that subtracting one number from 
>> another might be more efficient than comparing them for equality 
>> directly?
> 
> 
> The only difference between a CMP and a SUB instruction is where the 
> result ends up. But the CMP doesn't generate 0 or 1 as a result, it puts 
> the result in the FLAGS register. Converting the FLAGS to a 0 or 1 in a 
> register takes more instructions.
> 
>>> It's the 1/0 constraint on bools that causes the slowness, not the 
>>> size (stack is usually size_t-aligned anyway)
>>
>>
>> But if the function only tries to return 0 or 1 anyway, then what 
>> difference does it make?  At the moment, I can't think of an example 
>> of equality testing that can be made more efficient by being allowed 
>> to return a value other than 0 or 1.
> 
> 
> I can. (a == b), where a and b are ints, can be implemented as (a - b), 
> and the result is int 0 for equality, int !=0 for inequality.


So, why not treat false as 0, and true as not 0?  That way, it works 
just the same as the "int" version does (and comparing/testing against 
zero doesn't hit the address-bus). Yes, I can see some potential for 
concern there; but is there anything insurmountable?