Mixing operations with signed and unsigned types

[Stewart Gordon]

Michal Minich wrote:
> I was surprised by the behavior of division. The resulting type of 
> division in example below is uint and the value is incorrect. I would 
> expect that when one of operands is signed, then the result is signed 
> type. 

Going by the spec
http://www.digitalmars.com/d/1.0/type.html
"Usual Arithmetic Conversions"
the compiler is behaving correctly.  But see below....

<snip>
> auto f = a - b           // uint, 4294967288
> auto g = a + b           // uint, 4294967292
> auto h = a < b           // bool, false
> auto i = a > b           // bool, true
> 
> Recently while I was hunting some bug in templated code, I created a 
> templated function for operator <, which requires both arguments to be 
> either signed or unsigned.

It is in fact a bug that DMD accepts it.
http://www.digitalmars.com/d/1.0/expression.html#RelExpression
http://d.puremagic.com/issues/show_bug.cgi?id=259

> Fortunately D such function was quite easy to 
> do, if it wasn't possible I don't know if I would ever find form where 
> the ints and uints come from...
> 
> bool sameSign (A, B) () {
>     return isUnsigned!(A) && isUnsigned!(B)) || (isSigned!(A) && isSigned!
> (B);
> }
> 
> bool lt (A, B) (A a, B b) {
>     static assert (sameSign!(A, B) ());
>     return a < b;
> }
> 
> Could somebody please tell me why is this behavior, when mixing signed 
> and unsigned, preferred over one that computes correct result.

It would appear to be Walter's idea of C compatibility taking control 
again.

> If this cannot be changed, is it possible to just make compiler 
> error/warning when such incorrect calculation could occur. If it is 
> possible in D code to require same-signed types for function, it is 
> definitely possible for compiler to require explicit cast in such 
> cases.

I agree.  Either behave sensibly or generate an error.

Stewart.