Am 15.02.2011 23:43, schrieb Adam Ruppe:
> Daniel Gibson wrote:
>> Probably it would be helpful if size_t was a proper type that can't be mixed with other types in dangerous ways without explicit casting.
> 
> Bad idea: once you insert an explicit cast, you now have a *hidden* bug on the new platform instead of a compile error.

You should only cast when you know what you're doing..
If you get a compiler error on the new platform and just shut it up by doing an
explicit cast then, it's just as bad.
But having to do an explicit cast either way forces you to think about what
you're doing, hopefully avoiding large pieces of code that need to be rewritten
because they only worked because size_t was uint or such.

Cheers,
- Daniel

Adam Ruppe:

> Daniel Gibson wrote:
> > Probably it would be helpful if size_t was a proper type that can't be mixed with other types in dangerous ways without explicit casting.
> 
> Bad idea: once you insert an explicit cast, you now have a *hidden* bug on the new platform instead of a compile error.

I'll keep this in mind.

Bye,
bearophile

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.

"gölgeliyele" <usuldan@gmail.com> wrote in message news:ijfc4m$16p6$1@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.

> 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?
>
> That Nick doesn't like it? ;)

Nice try! But i was referring Don's argument. :)

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