Integer conversions too pedantic in 64-bit
Nick Sabalausky
a at a.a
Tue Feb 15 19:41:32 PST 2011
"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.
More information about the Digitalmars-d
mailing list