[phobos] std.array.ilength

[Don Clugston]

On 17 February 2011 17:10, David Simcha <dsimcha at gmail.com> 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 <dsimcha at gmail.com> 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 <dclugston at googlemail.com>
> wrote:
>>
>> On 17 February 2011 14:59, David Simcha <dsimcha at gmail.com> 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 ?)