why implicitly allowing compare ubyte and byte sucks

Derek Parnell derek at psych.ward
Thu Jun 11 19:22:20 PDT 2009


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.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell



More information about the Digitalmars-d mailing list