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

[Andrei Alexandrescu via Digitalmars-d]

On 11/19/14 2:03 AM, Don wrote:
> On Tuesday, 18 November 2014 at 18:23:52 UTC, Marco Leise wrote:
>> Am Tue, 18 Nov 2014 15:01:25 +0000
>> schrieb "Frank Like" <1150015857 at qq.com>:
>>
>>> > but now ,'int' is enough for use,not huge and not small,only > enough.
>>> > 'int' is easy to write,and most people are used to it.
>>> > Most importantly easier to migrate code,if  'length''s return
>>> >value type is 'int'.
>>>
>>> How about your idea?
>>
>> I get the idea of a broken record right now...
>> Clearly size_t (which I tend to alias with ℕ in my code for
>> brevity and coolness) can express more than 2^31-1 items, which
>> is appropriate to reflect the increase in usable memory per
>> application on 64-bit platforms. Yes, the 64-bit version of a
>> program or library can handle larger data sets. Just like it
>> was when people transitioned from 16-bit to 32-bit. I wont use
>> `int` just because the technically correct thing is `size_t`,
>> even it it is a little harder to type.
>
> This is difficult. Having arr.length return an unsigned type, is a
> dreadful language mistake.
>
>> Aside from the size factor, I personally prefer unsigned types
>> for countable stuff like array lengths. Mixed arithmetics
>> decay to unsinged anyways and you don't need checks like
>> `assert(idx >= 0)`. It is a matter of taste though and others
>> prefer languages with no unsigned types at all.
>
>
> No! No! No!  This is completely wrong. Unsigned does not mean
> "positive". It means "no sign", and therefore "wrapping semantics".
> eg length - 4 > 0, if length is 2.
>
> Weird consequence: using subtraction with an unsigned type is nearly
> always a bug.
>
> I wish D hadn't called unsigned integers 'uint'. They should have been
> called '__uint' or something. They should look ugly. You need a very,
> very good reason to use an unsigned type.
>
> We have a builtin type that is deadly but seductive.

I agree this applies to C and C++. Not quite to D. -- Andrei