problem with size_t and an easy solution

[Jonathan Marler via Digitalmars-d]

On Monday, 8 December 2014 at 14:29:09 UTC, ketmar via 
Digitalmars-d wrote:
> On Mon, 08 Dec 2014 14:00:25 +0000
> Jonathan Marler via Digitalmars-d <digitalmars-d at puremagic.com> 
> wrote:
>
>> On Monday, 8 December 2014 at 11:49:47 UTC, ketmar via 
>> Digitalmars-d wrote:
>> > On Mon, 08 Dec 2014 11:37:00 +0000
>> > Dominikus Dittes Scherkl via Digitalmars-d
>> > <digitalmars-d at puremagic.com> wrote:
>> >
>> >> On Monday, 8 December 2014 at 08:46:49 UTC, bearophile 
>> >> wrote:
>> >> > Freddy:
>> >> >
>> >> >> Why not keep size_t implictly convertable but disallow 
>> >> >> it for
>> >> >> usize.
>> >> >
>> >> > This is an interesting idea. (But the name "uword" seems 
>> >> > better).
>> >> YES.
>> >> And I want a signed variant of this (instead of the ugly 
>> >> ptrdiff_t):
>> >> I want to wield my sword!
>> > "uword" is meaningless, and "usize" is meaningfull. but i 
>> > like
>> > "sword"... yet i used to 16-bit words.
>> 
>> This is just my opinion and I could be persuaded otherwise but 
>> word/uword seem nicer.  It seems more descriptive, the size of 
>> a word on the system. Also I see less potential for name 
>> conflicts.
>>   The type "size" will probably conflict with alot of symbol 
>> names (function names/variables/etc).  I would be willing to 
>> bet this is why C/C++ initially used "size_t" instead of 
>> "size" in the first place.
> ah, there can't be "size" type, only "usize". we can't have 
> list or
> array with -3 items. ;-) and even if we want signed size, this 
> will be
> "ssize". we already have "byte" instead of "sbyte", it's PITA.

What about 'usize' and 'ptrdiff' ?  'ssize' seems a little ugly 
to me, but I realize this is just a matter of opinion.  
Personally I think this is a good idea, but I would be ok with 
multiple solutions.  'uword'/'usize' both seem ok to me.  I could 
even live with 'ssize'.

I have gotten use to using '_t' but you make a good point that 
since 'size_t' looks alien to D it encourages users to use the 
wrong type since it may look more consistent to the rest of their 
D code.  In my opinion, size_t needs to be treated more like a 
first class citizen, listed with all the other native types 
instead of being a footnote.  Maybe changing the name will help 
developers use it.