On Monday, February 14, 2011 18:11:10 Don wrote: > Nick Sabalausky wrote: > > "Jonathan M Davis" <jmdavisp...@gmx.com> wrote in message > > news:mailman.1650.1297733226.4748.digitalmar...@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