'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