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

[ketmar via Digitalmars-d]

On Wed, 19 Nov 2014 09:02:49 -0700
David Gileadi via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> On 11/19/14, 6:57 AM, ketmar via Digitalmars-d wrote:
> > On Wed, 19 Nov 2014 13:47:50 +0000
> > Don via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
> >> If I have two pencils of length 10 cm and 15 cm, then the first
> >> one is -5 cm longer than the other.
> > and again "length" is not a relation. show me pencil of length -10 cm.
> > when you substractin lengthes, you got completely different type as a
> > result, not "length" anymore. ah, that untyped real-life math! ;-)
> 
> To me the salient point is that this is not just a mess with real-life 
> math but also with math in D: lengths are unsigned but people subtract 
> them all the time. If they're (un)lucky this will return correct values 
> for a while, but then someday the lengths may be reversed and the values 
> will be hugely wrong:
> 
>      int[] a = [1, 2, 3];
>      int[] b = [5, 4, 3, 2, 1];
> 
>      writefln("%s", b.length - a.length);  // Yup, 2
>      writefln("%s", a.length - b.length);  // WAT? 18446744073709551614
> 
> This is why I agree with Don that:
> 
>  > Having arr.length return an unsigned type, is a dreadful language
>  > mistake.
ah, let range checking catch that. sure, there are edge cases where
range checking fails, but not so many.

besides, overflows are possible with signed ints too, so what signed
length does is simply hiding the bad code. any code reviewer must ring
a bell when he sees length subtraction without prior checking, be it
signed or unsigned. so there is no reason in negative lengthes anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141119/20a885ca/attachment.sig>