http://d.puremagic.com/issues/show_bug.cgi?id=259
--- Comment #24 from Don <[email protected]> 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: -------
