Trass3r un at
Fri Feb 3 11:28:04 PST 2012

> The same has to happen with druntime and Phobos2 or otherwise our  
> programs will break with every new release that deprecates or changes  
> non-template functions. That would probably be *every* release at the  
> moment, so it could look like this:
> /usr/lib64/     (link to /usr/lib64/
> /usr/lib64/
> /usr/lib64/
> /usr/lib64/
> /usr/lib64/     (link to /usr/lib64/
> /usr/lib64/
> /usr/lib64/
> /usr/lib64/

And you don't consider this insane?
The 'shared' approach is fine if a library has settled and is used  
pervasively like C runtime.
Also the library needs to have an appropriate development approach with  
major (feature) revisions and smaller non-breaking versions.
Phobos is a fast-moving target and doesn't fit in this model neither will  
it in the foreseeable future.

Why do people always treat D like a mainstream language? It isn't.
The chance that one has more than a few real D apps on one's machine is  
quite low. The chance that they use the very same version of  
phobos/druntime is even lower.
And usually the only ones you actually use are developed by yourself  

I rather have a slightly bigger executable than having my system cluttered  
with hundreds of phobos versions I don't need.
And you should keep in mind that dmd's phobos is currently 17MB, gdc's is  
25+5.5. Plus most apps only use a small share of that.

Making druntime shared sometime is ok I think, but it's just not ready  
yet. See the recent associative arrays dilemma. And the crappy GC.

More information about the Digitalmars-d mailing list