'int' is enough for 'length' to migrate code from x86 to x64

[Daniel Murphy via Digitalmars-d]

"H. S. Teoh via Digitalmars-d"  wrote in message 
news:mailman.2156.1416499421.9932.digitalmars-d at puremagic.com...

> By that logic, using an int to represent an integer is also using the
> incorrect type, because a signed type is *also* subject to module 2^^n
> arithmetic -- just a different form of it where the most negative value
> wraps around to the most positive values.  Fixed-width integers in
> computing are NOT the same thing as unrestricted integers in
> mathematics. No matter how you try to rationalize it, as long as you use
> hardware fix-width "integers", you're dealing with modulo arithmetic in
> one form or another. Pretending you're not, is the real source of said
> subtle bugs.

While what you've said is true, the typical range of values stored in an 
integral type is much more likely to cause unsigned wrapping than signed 
overflow.  So to get the desired 'integer-like' behaviour from D's integral 
types, you need to care about magnitude for signed types, or both magnitude 
and ordering for unsigned types.

eg 'a < b' becoming 'a - b < 0' is valid for integers, and small ints, but 
not valid for small uints unless a > b.  You will always have to care about 
the imperfect representation of mathematical integers, but with unsigned 
types you have an extra rule that is much more likely to affect typical 
code.