[phobos] std.array.ilength

[Andrei Alexandrescu]

I assume I'm in the minority here, but I don't see a need for such a 
function.

Andrei

On 2/17/11 1:40 PM, David Simcha wrote:
> 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
> <mailto:dclugston at googlemail.com>> wrote:
>
>     On 17 February 2011 17:10, David Simcha <dsimcha at gmail.com
>     <mailto: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
>     <mailto: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 <mailto:dclugston at googlemail.com>>
>      > wrote:
>      >>
>      >> On 17 February 2011 14:59, David Simcha <dsimcha at gmail.com
>     <mailto: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 <mailto:phobos at puremagic.com>
>     http://lists.puremagic.com/mailman/listinfo/phobos
>
>
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos