Small bikeshed here, but ilength seems akin to idup, where the 'i' means immutable.

I'm not against ilength, it's definitely understandable (hey, are we turning into Apple here?), but there is that possibility for confusion.

I have no better alternatives to offer however.

I agree it should be uint, and in that case, you should make this a noop when compiling on 32-bit systems.

-Steve



From: David Simcha <dsimcha at gmail.com>
To: Discuss the phobos library for D <phobos at puremagic.com>
Cc:
Sent: Thursday, February 17, 2011 8:59 AM
Subject: [phobos] std.array.ilength

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110217/f5bf74b1/attachment.html>