Integer conversions too pedantic in 64-bit

[Don]

Jonathan M Davis wrote:
> On Tuesday, February 15, 2011 14:00:12 Nick Sabalausky wrote:
>> "so" <so at so.so> wrote in message news:op.vqyk3emumpw3zg at 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.