[phobos] std.array.ilength

[David Simcha]

Fair points.  You've convinced me (since I didn't have a very strong opinion
before).  Let's go with int.  I've also come to believe that ilength is the
best name because it's negligible extra typing compared to .length, so
people will actually use it.  Proposed function for inclusion in object:

/**
Returns the length of an array as a 32-bit signed integer.  Verifies
with an assert that arr.length <= int.max unless this can be proven
at compile time.  This is a useful shortcut for getting the
length of a arrays that cannot plausibly have length longer than
int.max (about 2 billion) as a 32-bit integer even if building
for a 64-bit target.  It's also useful for converting an array length
to a signed integer while verifying the safety of this
conversion if asserts are enabled.
*/
@property int ilength(T)(const T[] arr) pure nothrow @safe {
    static if(size_t.sizeof > uint.sizeof || T.sizeof == 1) {
        assert(arr.length <= int.max,
            "Cannot get integer length of array with >int.max elements."
        );
    }

    return cast(int) arr.length;
}


On Thu, Feb 17, 2011 at 2:24 PM, Don Clugston <dclugston at googlemail.com>wrote:

> 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 ?)
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110217/2d3fd25b/attachment-0001.html>