On 17 February 2011 17:10, David Simcha <[email protected]> wrote: > Can you elaborate on why? Unsigned seems like the perfect type for an array > length.
An array length is a positive integer, you want to treat it as an integer, not as a bag of bits. Using an unsigned types is like using a cast, to be avoided whenever possible. They're a breeding ground for bugs, and a disturbingly large fraction of programmers don't understand them. On 17 February 2011 18:02, David Simcha <[email protected]> wrote: > My main gripe with going with int is that it eliminates the possibility of > making ilength() a noop that just returns .length on 32. The assert would > still be necessary. But the assert adds value. Note that an assert is only required on arrays of size 1 -- ubyte, byte, char. On everything else, it's still a no-op. > On Thu, Feb 17, 2011 at 9:48 AM, Don Clugston <[email protected]> > wrote: >> >> On 17 February 2011 14:59, David Simcha <[email protected]> wrote: >> > Hey guys, >> > >> > Kagamin just came up with a simple but great idea to mitigate the >> > pedantic >> > nature of 64-bit to 32-bit integer conversions in cases where using >> > size_t >> > doesn't cut it. Examples are storing arrays of indices into other >> > arrays, >> > where using size_t would be a colossal waste of space if it's safe to >> > assume >> > none of the arrays will be billions of elements long. >> > int or uint? I used int only b/c that was the example on the >> > newsgroup, >> > but I think uint makes more sense. >> >> I *strongly* oppose uint. We should take every possible opportunity to >> reduce usage of unsigned numbers. >> 'i' implies immutable. >> How about intlength (or intLength ?) _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
