Integer conversions too pedantic in 64-bit

[Nick Sabalausky]

"gölgeliyele" <usuldan at gmail.com> wrote in message 
news:ijfc4m$16p6$1 at digitalmars.com...
> On 2/15/11 12:24 PM, foobar wrote:
>> 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.
>
> Look at the basic data types:
>
> bool, byte, ubyte, short, ushort, int, uint, long, ulong, cent, ucent, 
> float, double, real, ifloat, idouble, ireal, cfloat, cdouble, creal, char, 
> wchar, dchar
> While size_t is just an alias, it will be used in a similar way to the 
> above. One can  see that it does not fit among these, stylistically 
> speaking. There seems to be a common pattern here, a prefixing character 
> is consistently used to differentiate basic types, such as u-short/short, 
> c-float/float, w-char/char, etc. I wonder if something similar can be done 
> for size_t. nint comes to mind, for native int, that is n-int. Sample 
> code:
>

I like "nint".

>   nint end = 0; // nintendo :)
>

Heh, I like that even more. It's "int eger;" for a new generation :)  And 
much less contrived, come to think of it.