On 19 February 2012 23:16, Stewart Gordon
<smjg_1998@yahoo.com> wrote:
On 19/02/2012 17:51, Manu wrote:
<snip>
Hang on ... are we talking here about some "native int", or the int type?
I don't really understand your resistance? I'm going to have the type when I need it, the
question is, will it be standardised, or will I (& everyone else) invent the name and
introduce a block of (probably not very portable) version() bullshit at the top of their
module?
I'm not saying we shouldn't have native integer types in D. Maybe what's needed is to be clearer on what's meant exactly by a native integer type. And then add the types to Phobos/druntime.
I particularly don't understand your suggestion of the names "size_t" and "ssize_t" for these types. They don't seem to me to denote the size of anything. I guess "nativeInt" and "nativeUint", defined in whatever module would be suitable, would be one possibility. Maybe someone has a better idea.
well ssize_t is an already established compliment to size_t, I guess it's identical to ptrdiff_t, but some CRT's seem to prefer the ssize_t name. Personally size_t and ssize_t make more sense to me than size_t and ptrdiff_t, which seems like a contradiction of terminology, although the 'ptr' name seems more fitting to what it actually is...
Ultimately I don't care, I suspect the prior commitment to size_t and ptrdiff_t can not be changed (although redefining their meaning would not be a breaking change, it just might show some cases of inappropriate usages)
I agree that nativeInt should probably be in the standard library, but I'm really not into that name. It's really long and ugly. That said, I basically hate size_t too, it doesn't seem very D-ish, reeks of C mischief... and C stuffs up those types so much. It's not dependable what they actually mean in C (ie. ptr size/native word size) on all compilers I've come in contact with :/
But knowing what code in Phobos/druntime should be using native integer types might help put the problem in better perspective.
Stewart.