Jonathan M Davis wrote:
On Tuesday, February 15, 2011 14:00:12 Nick Sabalausky wrote:
"so" <s...@so.so> wrote in message news:op.vqyk3emumpw3zg@so-pc...
I disagree that the discussion is pointless.
On the contrary, the OP pointed out some valid points:
1. that size_t is inconsistent with D's style guide. the "_t" suffix is
a C++ convention and not a D one. While it makes sense for [former?] C++
programmers it will confuse newcomers to D from other languages that
would expect the language to follow its own style guide.
2. the proposed change is backwards compatible - the OP asked for an
*additional* alias.
3. generic concepts should belong to the standard library and not user
code which is also where size_t is already defined.
IMO, we already have a byte type, it's plain common sense to extend this
with a "native word" type.
Funny thing is the most important argument against size_t got the least
attention.
I will leave it as an exercise for the reader.
That variables of type "size_t" are frequently used to store indicies
rather than the actual *size* of anything?
That it does nothing to help with 32/64-bit portability until you actually
compile your code both ways?
What _does_ have to do with 32/64-bit portability until you compile both ways?
Regardless of what the name is, it's still going to be the word size of the
machine and vary between 32-bit and 64-bit anyway.
size_t could be made a genuine type, and given a range of 0..2^^64-1,
even when it is a 32 bit value. Then, it'd fail to implicitly convert to
int, uint on 32 bit systems. But, if you did certain operations on it
(eg, & 0xFFFF_FFFF) then it could be store in a uint without a cast.
