I was wondering if D included size_t type at all, and if not what the type of .length would be. Finally I noticed "32 to 64 Bit Portability" mentioning it in portability section. How about mentioning it and ptrdiff_t at least in types section too?

So, since it exists, shouldn't it also be used in Phobos library rather than restricting everything to uint?

I also noticed std.file.getSize() is documented to return uint, shouldn't
it be at least ulong?

It would also be nice to be able to get compiler warnings with signed/unsigned comparisions and when assigning/passing an integer potentially truncates it.

"Timo Sirainen" <tss@iki.fi> wrote in message news:pan.2004.06.12.17.25.52.733397@tss.iki.fi...
> I was wondering if D included size_t type at all, and if not what the type of .length would be. Finally I noticed "32 to 64 Bit Portability" mentioning it in portability section. How about mentioning it and ptrdiff_t at least in types section too?

It does have them.

There's some mileage in Java's utilitarian type-system - i.e. you only get what come with the language - and I think Walter hates typedefs/aliases (from having been forced to eat too much bad C food), but I do think there's a middle ground. It's sensible, to me at least, to have these two well-established aliases in our standard (Phobos) bad, since they abstract away concerns of the architecture.

> So, since it exists, shouldn't it also be used in Phobos library rather than restricting everything to uint?

Yes. Wherever appropriate.

> I also noticed std.file.getSize() is documented to return uint, shouldn't
> it be at least ulong?

Most certainly.

> It would also be nice to be able to get compiler warnings with signed/unsigned comparisions and when assigning/passing an integer potentially truncates it.

Oops. You've opened one of our pet hornet's nests. I am honour bound not to comment, so I'll just stand back and watch the debate spring to life, as a Phoenix from the flames ...