On Tuesday, 18 November 2014 at 14:24:18 UTC, FrankLike wrote:
>
> Many excellent projects such as dfl,dgui,tango, many 'length' which type is 'int' or 'uint',they are D's,many people like it.but they should migrate to 64 bit.So if 'length' type is 'int',they can work on 64 bit,but now,they must be modify for 'length''s type.

The type of 'length' has always been size_t, which is aliased to uint on x86 and ulong on x64.  I think an argument could be made for using long instead of ulong, but the switch from unsigned to signed across bus widths could result in portability issues (when building an x64 program for x86).

On Tuesday, 18 November 2014 at 12:33:52 UTC, FrankLike wrote:
> If you migrate your projct from x86 to x64,you will find the length is error,you must modify it ,such as:
>   int i= (something).length
> to
>   size_t i = (something).length
>
> 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'.
>
> Thank you all.

This is a weird thing to argue.

just because an int is good enough for you does not mean that it is the best thing for all people.

Isn't the purpose of size_t is to be large enough to address all available memory? A negative value is not only too small but doesn't make sense when discussing lengths.

Correctness requires using size_t.

On Tue, 18 Nov 2014 17:59:04 +0000
David Eagen via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Isn't the purpose of size_t is to be large enough to address all available memory? A negative value is not only too small but doesn't make sense when discussing lengths.
> 
> Correctness requires using size_t.
yes. besides, there is no such thing as "negative length", so it's somewhat... weird to use signed integer for length.

Am Tue, 18 Nov 2014 15:01:25 +0000
schrieb "Frank Like" <1150015857@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.

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.

-- 
Marco

> 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

I known it.

but if you compile the dfl Library to 64 bit,you will find error:

core.sys.windows.windows.WaitForMultipleObjects(uint nCount,void** lpHandles,....) is not callable using argument types(ulong,void**,...)

the 'WaitForMultipleObjects' Function is in dmd2/src/druntime/src/core/sys/windows/windows.d

the argument of first is dfl's value ,it come from a 'length' ,it's type is size_t,now it is 'ulong' on 64 bit.

So druntime must keep the same as  phobos for size_t.

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@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.

On Wednesday, 19 November 2014 at 09:06:16 UTC, Maroc Leise wrote:
> Clearly size_t (which I tend to alias with ℕ in my code for
> brevity and coolness)
No, this is far from the implied infinite set.
A much better candidate for ℕ is BigUInt (and ℤ for BigInt)

On Tuesday, 18 November 2014 at 18:03:35 UTC, ketmar via Digitalmars-d wrote:
> On Tue, 18 Nov 2014 17:59:04 +0000
> David Eagen via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> Isn't the purpose of size_t is to be large enough to address all available memory? A negative value is not only too small but doesn't make sense when discussing lengths.
>> 
>> Correctness requires using size_t.
> yes. besides, there is no such thing as "negative length", so it's
> somewhat... weird to use signed integer for length.

The reason is so that D won't mess with implicit signed-unsigned conversion, not negative length.

On Tuesday, 18 November 2014 at 18:23:52 UTC, Marco Leise wrote:
> 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)`.

Failing assert(-1 < arr.length) make little sense though, -1 can't be bigger than a non-negative number.