Integer conversions too pedantic in 64-bit

[gölgeliyele]

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:

   nint end = 0; // nintendo :)

Having too many aliases seems like a problem to me. Different developers 
will start using different names and reading code will become harder. 
One would need to learn two things that refer to the same.

My 2 cents: I suggest deprecating size_t and replacing it with a better 
alternative that fits with the D language.