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.

To draw a comparison, arr.capacity, arr.assumeSafeAppend and arr.reserve() are all in object.di.

-Steve



----- Original Message -----
> 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

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.

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.

On Thu, Feb 17, 2011 at 9:31 AM, Steve Schveighoffer <schveiguy at yahoo.com>wrote:

> 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.
>
> To draw a comparison, arr.capacity, arr.assumeSafeAppend and arr.reserve()
> are all in object.di.
>
> -Steve
>
>
>
> ----- Original Message -----
> > 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
>
>
>
>
> _______________________________________________
> 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/6bed426e/attachment-0001.html>

In DWT there is a module called dwt.std that publicly imports the most common packages. Maybe something similar could be used in Phobos but just a couple of functions and not whole packages. A better name would probably be needed, std.std looks kind of silly.

-- 
/Jacob Carlborg

On 17 feb 2011, at 16:13, David Simcha wrote:

> 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.
> 
> 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.
> 
> On Thu, Feb 17, 2011 at 9:31 AM, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
> 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.
> 
> To draw a comparison, arr.capacity, arr.assumeSafeAppend and arr.reserve() are all in object.di.
> 
> -Steve
> 
> 
> 
> ----- Original Message -----
> > 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
> 
> 
> 
> 
> _______________________________________________
> phobos mailing list
> 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

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

On 02/17/2011 04:13 PM, David Simcha wrote:
> 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.

Same for me, except it's a module template that imports name er name about 1 dozen funcs I use all the time. (Plus a custom join that auto converts to string; cannot understand why the original one doesn't do it.)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com