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 <[email protected]>wrote: > On 17 February 2011 14:59, David Simcha <[email protected]> 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 > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos >
_______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
