why implicitly allowing compare ubyte and byte sucks

[Don]

Rainer Deyke wrote:
> Don wrote:
>> 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.
> 
> I disagree.  In fact, I don't sign extension or conversion to a common
> type should even be necessary.

Doing _no_ extension doesn't cause problems, of course.

> 
> Given value 's' of type 'sT' and unsigned value 'u' of type 'uT', where
> 'sT' and 'uT' have the same width, comparisons should be translated as
> follows:
>   's == u' --> 's >= 0 && cast(uT)(s) == u'
>   's != u' --> 's < 0 || cast(uT)(s) != u'
>   's < u' --> 's < 0 || cast(uT)(s) < u'
>   's <= u' --> 's < 0 || cast(uT)(s) <= u'
>   's > u' --> 's >= 0 && cast(uT)(s) > u'
>   's >= u' --> 's > 0 && cast(uT)(s) >= u'
> 
> This system would always work, even when no type exists that can hold
> all possible values of both 'sT' and 'uT'.  And it would always be
> *correct*, i.e. negative values would always be smaller than and
> different from positive values, even when the positive value is outside
> the range of any signed type.

That's true. What you are doing is removing the int/byte inconsistency, 
by making  uint == int comparisons behave the same way that ubyte == 
byte comparisons do now.
Notice that your proposal
(1) preserves the existing behaviour of byte==ubyte (which the original 
poster was complaing about);
(2) silently changes the behaviour of existing D and C code (that 
involves int==uint); and
(3) assumes that the code as written is what the programmer intended. I 
suspect that this type of code is frequently an indicator of a bug. 
Consider:

const ubyte u = 0xFF;
byte b;
if (b == u) ...

After your transformation, this will be:

if (false) ...

But actually the code has a simple bug: b should have been ubyte. I 
think this is a pretty common bug (I've done it several times myself).

(2) is fatal, I think.