phobos alt.

[bls]

On 10/29/2011 05:26 PM, Jonathan M Davis wrote:
> f you want to have or use a 3rd party library, that's fine. But there's no
> reason to put such a library inside of the standard library. That's just
> confusing to people. std.container is how Phobos is going to do containers. It
> needs to be fleshed out, and it's possible that its API needs some refinement,
> but sticking alternate implementations of things inside of the standard
> library is just confusing and schizophrenic. The standard library will have
> what it will have and implement that how it implements it. It's
> counterproductive to put a bunch of different ways to do the same thing in the
> standard library. If someone wants a different design or implementation, they
> can create or use 3rd party library which does that. There's no need for it to
> be officially sanctioned in the standard library. So, if someone wants to use
> dcollections, then let them use dcollections, but that's no reason to stick it
> in Phobos which already has a different design for how its containers work.

Hi Jonathan,
I think I get your point. And sure there are pros and cons Since I am 
convinced that there are more pros (otherwise I would simply shut up) 
Let me try to argue for my position.

let's start with std.xml I guess you will agree that std.xml is ahem.. 
not perfect. Now there is something better, on dsource, google, git, 
Dunno.  Isn't better to have such an alt.xml lib handy..without searching ?

Let's take collections, Here we have atm nothing comparable in phobos. 
Let me ask : Having dcollections in phobos ..Will it break some 
_existing_ code ?

Not my last argument.. but heck I am tiered. Simple, but important 
libraries are hanging around, {somewhere}, a guid lib, a crypt lib, a 
financial math lib. etc. why not having *alt.* as say.. incubator.
A+
Bjoern