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 ilength(T)(T[] arr) {
     assert(arr.length <= int.max);
     return cast(int) arr.length;
}

Usage:

int[] indices;
auto array = returnsArray();
indices ~= array.ilength;

This cuts down on the excessive verbosity of an explicit cast that's safe 99.999 % of the time and encourages sprinkling it into code even if for the foreseeable future it will be compiled in 32-bit mode.

Two questions:

1.  Is everyone ok with me adding this as a convenience function to
std.array?
2.  int or uint?  I used int only b/c that was the example on the
newsgroup, but I think uint makes more sense.

--David Simcha

I'm not sure I see the improvement over a cast. If anything it makes everything more comfy and therefore riskier.

What's wrong with to!int(arr.length)? It's safe too.


Andrei

On 2/17/11 7:59 AM, David Simcha 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 ilength(T)(T[] arr) {
> assert(arr.length <= int.max);
> return cast(int) arr.length;
> }
>
> Usage:
>
> int[] indices;
> auto array = returnsArray();
> indices ~= array.ilength;
>
> This cuts down on the excessive verbosity of an explicit cast that's safe 99.999 % of the time and encourages sprinkling it into code even if for the foreseeable future it will be compiled in 32-bit mode.
>
> Two questions:
>
> 1. Is everyone ok with me adding this as a convenience function to
> std.array?
> 2. int or uint? I used int only b/c that was the example on the
> newsgroup, but I think uint makes more sense.
>
> --David Simcha
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

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 ilength(T)(T[] arr) {
> ? ?assert(arr.length <= int.max);
> ? ?return cast(int) arr.length;
> }
>
> Usage:
>
> int[] indices;
> auto array = returnsArray();
> indices ~= array.ilength;
>
> This cuts down on the excessive verbosity of an explicit cast that's safe 99.999 % of the time and encourages sprinkling it into code even if for the foreseeable future it will be compiled in 32-bit mode.
>
> Two questions:
>
> 1. ?Is everyone ok with me adding this as a convenience function to
> std.array?
> 2. ?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 ?)

On Thu, 2011-02-17 at 15:48 +0100, Don Clugston 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 ilength(T)(T[] arr) {
> >    assert(arr.length <= int.max);
> >    return cast(int) arr.length;
> > }
> >
> > Usage:
> >
> > int[] indices;
> > auto array = returnsArray();
> > indices ~= array.ilength;
> >
> > This cuts down on the excessive verbosity of an explicit cast that's safe 99.999 % of the time and encourages sprinkling it into code even if for the foreseeable future it will be compiled in 32-bit mode.
> >
> > Two questions:
> >
> > 1.  Is everyone ok with me adding this as a convenience function to
> > std.array?
> > 2.  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 ?)

Other suggestions:

slength  (signed length / short length)
length32

-Lars

On Thu, Feb 17, 2011 at 9:14 AM, Andrei Alexandrescu <andrei at erdani.com>wrote:

> I'm not sure I see the improvement over a cast. If anything it makes everything more comfy and therefore riskier.
>
> What's wrong with to!int(arr.length)? It's safe too.
>
>
Too verbose and (because of runtime checks) inefficient for something that's safe 99.999% of the time and useful fairly often in practice.  IDK if it's just my programming style but I use arrays of indices into other arrays all the time.  Really, when's the last time you worked with an array over 2 billion elements long (or 4 billion if we go with uint)?  It's just frustrating to put up with all these formalities in the overwhelmingly common cases (where array.length < int.max is a safe assumption) for added safety in the extremely rare case where it's not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110217/46846e4d/attachment.html>

slength is good.  length32 is too hard to type.  I really want something almost as terse as .length that can be used all over the place, anywhere it's safe to assume that an array won't be billions of elements long.

On Thu, Feb 17, 2011 at 9:54 AM, Lars Tandle Kyllingstad <lars at kyllingen.net
> wrote:

> On Thu, 2011-02-17 at 15:48 +0100, Don Clugston 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 ilength(T)(T[] arr) {
> > >    assert(arr.length <= int.max);
> > >    return cast(int) arr.length;
> > > }
> > >
> > > Usage:
> > >
> > > int[] indices;
> > > auto array = returnsArray();
> > > indices ~= array.ilength;
> > >
> > > This cuts down on the excessive verbosity of an explicit cast that's
> safe
> > > 99.999 % of the time and encourages sprinkling it into code even if for
> the
> > > foreseeable future it will be compiled in 32-bit mode.
> > >
> > > Two questions:
> > >
> > > 1.  Is everyone ok with me adding this as a convenience function to
> > > std.array?
> > > 2.  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 ?)
>
> Other suggestions:
>
> slength  (signed length / short length)
> length32
>
> -Lars
>
> _______________________________________________
> 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/d8da7376/attachment.html>

Can you elaborate on why?  Unsigned seems like the perfect type for an array length.

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 ilength(T)(T[] arr) {
> >    assert(arr.length <= int.max);
> >    return cast(int) arr.length;
> > }
> >
> > Usage:
> >
> > int[] indices;
> > auto array = returnsArray();
> > indices ~= array.ilength;
> >
> > This cuts down on the excessive verbosity of an explicit cast that's safe 99.999 % of the time and encourages sprinkling it into code even if for
> the
> > foreseeable future it will be compiled in 32-bit mode.
> >
> > Two questions:
> >
> > 1.  Is everyone ok with me adding this as a convenience function to
> > std.array?
> > 2.  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/858706da/attachment.html>

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.

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 ilength(T)(T[] arr) {
> >    assert(arr.length <= int.max);
> >    return cast(int) arr.length;
> > }
> >
> > Usage:
> >
> > int[] indices;
> > auto array = returnsArray();
> > indices ~= array.ilength;
> >
> > This cuts down on the excessive verbosity of an explicit cast that's safe 99.999 % of the time and encourages sprinkling it into code even if for
> the
> > foreseeable future it will be compiled in 32-bit mode.
> >
> > Two questions:
> >
> > 1.  Is everyone ok with me adding this as a convenience function to
> > std.array?
> > 2.  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/be64feaa/attachment-0001.html>

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 ?)

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>