int opEquals(Object), and other legacy ints

[Frits van Bommel]

kris wrote:
> Frits van Bommel wrote:
>> kris wrote:
>>
>>> Walter Bright wrote:
>>>
>>>> Stewart Gordon wrote:
>>>>
>>>>> 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?
>>
>>
>> Then what would happen if a and b differ by, say, 256? Remember, an 
>> int is 4 bytes, a bool is only 1.
> 
> Sure, but it's generally more efficient to do all logical and arithmetic 
> operations in the native width of the device anyway ~ generally 32bits 
> for current D compilers.
> 
> If you're talking about issues related to actually storing a bool 
> result, then that's part of the "concerns" noted above. Bool values 
> derived in certains ways may need to be folded for storage, but not for 
> testing. The subtraction case above may be included in that group, but 
> testing should still only require a compare against zero (for both true 
> and false). I'm suggesting only that zero values should *always* be used 
> to test for 'truth' ~ never 1, or 255, or any value other than zero. 
> Anywhere the keyword "true" is used (or implied) for comparative 
> purposes, test against zero and invert the jmp-condition instead. If 
> that's not done already, it would probably speed things up in many cases.

Actually, I'm pretty sure testing for zero is already how it's done 
(just with 1-byte operands instead of 4-byte ones).

Something else: if there are multiple ways to represent true then 
equality testing just got a lot more complicated :).