Vote++, though I'd venture to say the same thing about min(), max(), array(), and a few other misc goodies from std.array, std.algorithm, std.functional and std.range.  This would make D a much better language for small/scripting programs, if you didn't have the friction of having to import all these small convenience functions.<br>
<br>Right now my solution is that I have a module called custom.phobos (custom is my very uncreative namespace for libs that I write that are not intended to be release quality and are just for personal use) that publicly imports all the Phobos modules that I use just about everywhere.  std.all would have been a great idea, except it causes too many naming collisions and the need to use qualified names.<br>
<br><div class="gmail_quote">On Thu, Feb 17, 2011 at 9:31 AM, Steve Schveighoffer <span dir="ltr"><<a href="mailto:schveiguy@yahoo.com">schveiguy@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
BTW, I think perhaps this should go in object.di.  It's a small enough template that it won't add too much bulk, and it would be nice to have this available at all times without having to import std.array.<br>
<br>
To draw a comparison, arr.capacity, arr.assumeSafeAppend and arr.reserve() are all in object.di.<br>
<font color="#888888"><br>
-Steve<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
----- Original Message -----<br>
> From:David Simcha <<a href="mailto:dsimcha@gmail.com">dsimcha@gmail.com</a>><br>
> To:Discuss the phobos library for D <<a href="mailto:phobos@puremagic.com">phobos@puremagic.com</a>><br>
> Cc:<br>
> Sent:Thursday, February 17, 2011 8:59 AM<br>
> Subject:[phobos] std.array.ilength<br>
><br>
> Hey guys,<br>
><br>
> Kagamin just came up with a simple but great idea to mitigate the pedantic<br>
> nature of 64-bit to 32-bit integer conversions in cases where using size_t<br>
> doesn't cut it.  Examples are storing arrays of indices into other arrays,<br>
> where using size_t would be a colossal waste of space if it's safe to assume<br>
> none of the arrays will be billions of elements long.<br>
><br>
> int ilength(T)(T[] arr) {<br>
>     assert(arr.length <= int.max);<br>
>     return cast(int) arr.length;<br>
> }<br>
><br>
> Usage:<br>
><br>
> int[] indices;<br>
> auto array = returnsArray();<br>
> indices ~= array.ilength;<br>
><br>
> This cuts down on the excessive verbosity of an explicit cast that's safe<br>
> 99.999 % of the time and encourages sprinkling it into code even if for the<br>
> foreseeable future it will be compiled in 32-bit mode.<br>
><br>
> Two questions:<br>
><br>
> 1.  Is everyone ok with me adding this as a convenience function to std.array?<br>
> 2.  int or uint?  I used int only b/c that was the example on the newsgroup, but<br>
> I think uint makes more sense.<br>
><br>
> --David Simcha<br>
> _______________________________________________<br>
> phobos mailing list<br>
> <a href="mailto:phobos@puremagic.com">phobos@puremagic.com</a><br>
> <a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
phobos mailing list<br>
<a href="mailto:phobos@puremagic.com">phobos@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a><br>
</div></div></blockquote></div><br>