On 3/13/2011 5:56 PM, Jonas Drewsen wrote:
It's a great idea. But I think there need to be some kind of janitor for
the 'etc' modules so that it does not end up as a new dsource collection
of many unmaintained, some dead and a few live projects.
I don't see why this is a concern. This is what I have in mind:
1. There are a lot of good C libraries out there, some of which are
generally useful enough to be in a standard library and are license
compatible with Phobos. My thoughts are that we would only include very
stable C libs that are unlikely to require significant maintenance
effort. My personal short list is libcurl (looks like it's already
happening), SQLite, libpng, and, if we can get a binary attribution
clause waiver, libbzip2.
2. The hassle of compiling the C code, translating the header, etc. is
a significant and annoying transaction cost that probably deters people
from writing good D wrappers and leads to lots of duplication of effort
among people who are kinda sorta considering writing one.
3. Even if someone doesn't intend to write a wrapper initially, they
may start using the C API directly and eventually end up refactoring out
a good wrapper from the project that uses the C API. This is more
likely if the C API is already there, waiting to be used.
4. Even if a D wrapper is not written for a long time, having the plain
C API available for those that want to use it is substantially better
than nothing, and the C API will not go away once a D wrapper is written.
