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

[Don via Digitalmars-d]

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.