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.
signature.asc
Description: PGP signature
