int opEquals(Object), and other legacy ints

[kris]

Walter Bright wrote:
> Bruno Medeiros wrote:
> 
>> Well, let's think about the other way around then. Why should bool be 
>> constrained to 0 or 1? Why not, same as kris said, 0 would be false, 
>> and non zero would be true. Then we could have an opEquals or any 
>> function returning a bool instead of int, without penalty loss.
>>
>> The only shortcoming I see is that it would be slower to compare two 
>> bool /variables/:
>>    (b1 == b2)
>> that expression is currently just 1 instruction, a CMP, but without 
>> the 0,1 restriction it would be more (3, I think, have to check that). 
>> However, is that significantly worse? I think not. I think comparison 
>> between two bool _variables_ is likely very rare, and when it happens 
>> it is also probably not performance critical. (statistical references?)
>> Note: this would not affect at all comparisons between a bool variable 
>> and a bool literal. Like (b == true) or (b == false).
> 
> 
> I think most programmers would find this to be very surprising behavior. 
> I know I would.

That's assuming they'd ever notice. But then it's hardly worth exploring 
alternate strategies when there's the sete/setz instruction just begging 
to be leveraged instead?