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 <[email protected]> 
> 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 <[email protected]>
> > To:Discuss the phobos library for D <[email protected]>
> > 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
> > [email protected]
> > http://lists.puremagic.com/mailman/listinfo/phobos
> 
> 
> 
> 
> _______________________________________________
> phobos mailing list
> [email protected]
> http://lists.puremagic.com/mailman/listinfo/phobos
> 
> _______________________________________________
> phobos mailing list
> [email protected]
> http://lists.puremagic.com/mailman/listinfo/phobos

_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos

Reply via email to