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