[Issue 259] Comparing signed to unsigned does not generate an error

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=259



--- Comment #24 from Don <clugdbug at yahoo.com.au> 2011-11-25 04:05:29 PST ---
It seems wrong to me that:

if (-1 < 2u) {...}
fails to compile. Both are in the range -int.max .. int.max, so they can safely
be compared using signed comparison.

The problems with mixed sign are when one operand can be in the range
-int.max..0 and the other can be in the range int.max+1u..uint.max. If at least
one of the operands is in the polysemous range 0..int.max, there should be no
problem.

But, the patch as it stands allows a polysemous-ranged int to be compared with
a uint, but does not allow a polysemous-range uint to be compared with an int.
At present the spec doesn't give any reason for unsigned to be treated from
signed.

The problem is the silly C promotion rule that converts both operands to
unsigned (instead, it should generate an error). In any existing C code that
works, it works because the signed operand is in the polysemous range. Of
course there could be code which relies on (-1<2u) being false. But surely such
code is broken.

Do we really need to retain backwards compatibility with broken C code?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------