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

via Digitalmars-d digitalmars-d at puremagic.com
Wed Nov 19 10:20:24 PST 2014


On Wednesday, 19 November 2014 at 16:02:50 UTC, David Gileadi 
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.

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. Let people cast the result 
if they want wrapping (or better, use a helper function to 
document the intentiion).


More information about the Digitalmars-d mailing list