Integer conversions too pedantic in 64-bit

[Jonathan M Davis]

On Monday, February 14, 2011 18:11:10 Don wrote:
> Nick Sabalausky wrote:
> > "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> > news:mailman.1650.1297733226.4748.digitalmars-d at puremagic.com...
> > 
> >> On Monday, February 14, 2011 17:06:43 spir wrote:
> >>> Rename size-t, or rather introduce a meaningful standard alias? (would
> >>> vote
> >>> for Natural)
> >> 
> >> Why? size_t is what's used in C++. It's well known and what lots of
> >> programmers
> >> would expect What would you gain by renaming it?
> > 
> > Although I fully realize how much this sounds like making a big deal out
> > of nothing, to me, using "size_t" has always felt really clumsy and
> > awkward. I think it's partly because of using an underscore in such an
> > otherwise short identifier, and partly because I've been aware of size_t
> > for years and still don't have the slightest clue WTF that "t" means.
> > Something like "wordsize" would make a lot more sense and frankly feel
> > much nicer.
> > 
> > And, of course, there's a lot of well-known things in C++ that D
> > deliberately destroys. D is a different language, it may as well do
> > things better.
> 
> To my mind, a bigger problem is that size_t is WRONG. It should be an
> integer. NOT unsigned.

Why exactly should it be signed? You're not going to index an array with a 
negative value (bounds checking would blow up on that I would think, though IIRC 
you can do that in C/C++ - which is a fairly stupid thing to do IMHO). You lose 
half the possible length of arrays if you have a signed size_t (less of a 
problem in 64-bit land than 32-bit land). I don't see any benefit to it being 
signed other than you can have a for loop do something like this:

for(size_t i = a.length - 1; i >= 0; --i)

And while that can be annoying at times, it's not like it's all that hard to 
code around.

Is there some low level reason why size_t should be signed or something I'm 
completely missing?

- Jonathan M Davis