default random object?

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> > Also, dsimcha said:
> >  > This is purely a convenience feature for when you want
> >  > random number generation to "just work" even if it's not the most
> >  > efficient thing
> >  > in the world.
> >
> > I agree to him. If you need efficiency, you can write your own code or
> > use a highly specialized library fit for the job. Most users probably
> > wouldn't rely on the standard library if they're optimizing their code.
> Well, you see, here's where we can "agree to disagree" (as much as I
> dislike the PCness of the phrase). IMHO, if most users in search for
> efficiency need to roll their own counterparts of the abstractions
> provided by Phobos, I've majorly wasted my time. Costly abstractions are
> a dime a dozen. I have nothing but contempt for them. Every dog language
> has them in spades. The real challenge is not to write sort in three
> lines. It's to write it in three lines and have it beat the 2000 lines
> sort. (Alas, we're not there yet.)
>  > As long as the user _can_ write his own code, the standard library
>  > should prefer to be simple and easy to use. It also prevents bitrot,
>  > bloat, and incomprehensible library code.
> This approach seems to be pushing bitrot, bloat, and incomprehensibility
> into the user code, while keeping the library a collection of useless
> toys. Hardly an approach I'd go for. I am sorry. I just disagree.
> Andrei

Just to set the record straight, I actually agree with Andrei here.  Elegant but
costly abstractions are simply not D's niche, and are relatively easy to come by.
 If you want them, use a good dynamic interpreted language instead.  The quote
above was taken out of context.  I believe that a library should provide efficient
and flexible abstractions that eliminate the need for people to roll their own and
that the goal of Phobos2 in this regard is a good one.  I probably wouldn't use
much of what was in std.algorithm, at least in the performance critical parts of
my code, if it were pass-by-delegate instead of pass-by-alias.  My only point was
that, when complexity in the API (or language) is unavoidable if efficiency and
flexibility are to be achieved, I think it's ok to slap a few not-so-efficient
convenience features on top of it as long as the core remains efficient, flexible
and reasonably usable.