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@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@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.
