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. - Jonathan M Davis