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

[via Digitalmars-d]

On Friday, 21 November 2014 at 21:44:25 UTC, Marco Leise wrote:
> Am Wed, 19 Nov 2014 18:20:24 +0000
> schrieb "Marc Schütz" <schuetzm at gmx.net>:
>
>> I'd say length being unsigned is fine. The real mistake is 
>> that the difference between two unsigned values isn't signed, 
>> which would be the most "correct" behaviour.
>
> Now take my position where I explicitly write code relying
> on the fact that `bigger - smaller` yields correct results.
>
> uint bigger = uint.max;
> uint smaller = 2;
> if (bigger > smaller)
> {
>     auto added = bigger - smaller;
>     // Now 'added' is an int with the value -3 !
> }
> else
> {
>     auto removed = smaller - bigger;
> }
>
> In fact checking which value is larger is the only way to
> handle the full result range of subtracting two machine
> integers which is ~2 times larger than what the original type
> can handle:
>
> T.min - T.max .. T.max - T.min
>
> This is one reason why I'd like to just keep working with
> the original unsigned type, but split the range around the
> positive/negative pivot with an if-else.
>
> Implicit conversion of unsigned subtractions to signed values
> would make the above code unnecessarily hard.

Yes, that's true. However, I doubt that this is a common case. 
I'd say that when two values are to be subtracted (signed or 
unsigned), and there's no knowledge about which one is larger, 
it's more useful to get a signed difference. This should be 
correct in most cases, because I believe it is more likely that 
the two values are close to each other. It only becomes a problem 
when they're an opposite sides of the value range.

Unfortunately, no matter how you turn it, there will always be 
corner cases that a) will be wrong and b) the compiler will allow 
silently. So the question becomes one of preferences between 
usefulness for common use cases, ease of detection of errors, and 
compatibility.