why implicitly allowing compare ubyte and byte sucks

[Don]

Derek Parnell wrote:
> On Fri, 12 Jun 2009 02:08:14 +0200, Don wrote:
> 
>> Walter Bright wrote:
>>> davidl wrote:
>>>> It seems that comparing two different operands with different size 
>>>> makes no sense. The compiler should issue an error against that.
>>> Consider:
>>>
>>>    byte b;
>>>    if (b == 1)
>>>
>>> here you're comparing two different sizes, a byte and an int. 
>>> Disallowing such (in its various incarnations) is a heavy burden, as the 
>>> user will have to insert lots of ugly casts.
>>>
>>> There really isn't any escaping from the underlying representation of 
>>> 2's complement arithmetic with its overflows, wrap-arounds, sign 
>>> extensions, etc.
>> The problem is a lot more specific than that.
>> The unexpected behaviour comes from the method used to promote two types 
>> to a common type, when both are smaller than int, but of different 
>> signedness. Intuitively, you expect the common type of {byte, ubyte} to 
>> be ubyte, by analogy to {int, uint}->uint, and {long, ulong}->ulong. But 
>> instead, the common type is int!
> 
> I think that the common type for byte and ubyte is short. Byte and ubyte
> have overlapping ranges of values (-127 to 127) and (0 to 255) so a common
> type would have to be able to hold both these ranges at least, and short
> (16-bit signed integer) does that.

But then you still have the problem that the high half of the short was 
extended from the low half in two different ways, once by sign-extend, 
once by zero-extend. Mixing sign-extend and zero-extend in the same 
expression is asking for trouble.