I want to encourage everyone to help out with the library. My primary focus,
as you all have guessed by now, is making the compiler itself the best it
can be. Phobos has been a bit neglected as a result. I, of course, will take
on the task of the necessary runtime support for the language semantics,
such as making sure the exception handling stack unwinder works. But the
stuff that makes a library full and great, I'm not too good at.
A couple philosophical points on what I think makes a good library:
1) Loose coupling. This is important so that small apps can be created. In
Java, it turned out that every class was dependent on every other class, so
the smallest app pulled in the entire library. Library modules should be as
decoupled as practical. Calling a directory function shouldn't pull in 100k
2) The C standard library is not a good module to be emulated. While the C
standard library should be available via c.stdio, that's it. C file I/O is
particularly slow due to the double buffering it requires.
3) Core library stuff should be easilly implementable on both win32 and
linux. With those two covered, it shouldn't be too much trouble to take it
4) Modules should be a thin veneer over operating system API's. This will
alleviate the temptation of bypassing them and calling the OS directly.
5) Performance matters.
6) Size matters.
7) Make use of the in, out, invariant and unittest features, especially the
8) As always, be real careful about copyrights. A standard library that's
encumbered by disinterested third party copyrights will be a boat anchor
holding us all back. D needs to be IP clean, it's the right thing to do.
When in any doubt, write it from scratch.
9) Put your name in the code you write! You'll be famous as one of the D
I think we can learn a lot from how the Python libraries are organized.
Their creators seem to know what they're doing <g>.