I think there might be a few tricks to improve the C API without adding any new code. For example, replace by-pointer parameter declarations with _out_ parameters when applicable (the underlying function signature is the same), replace const parameters with in parameters, etc. This won't change the C API a single bit (won't even add new code), but will vastly improve readability and sometimes safety of the API. In other cases, some minor additions could be made, for example: libjpeg provides API to register error handlers, instead of setting errno and such. Those kind of situations could be used to throw exceptions. It only takes a static this() and a few lines of code. In case those kind of modifications/additions are made, there could be a standard way to disable them and use the original version.
On Mon, Oct 17, 2011 at 6:02 AM, Walter Bright <newshou...@digitalmars.com> wrote: > Brad and I were talking about some D code that needed openssl support, when > we ran into the same old problem: > > No D files corresponding to the openssl C .h files. > > It's not that these are a big problem to create, it's just that they are not > done, and it tends to turn off people from using D. D is binary API > compatible with C, but only with a corresponding D import file. This, out of > the box, makes D *harder* to use than C. > > Lots of people roll their own, but that work is hard to find and haphazard. > > This problem keeps coming up again and again. > > So I propose creating, on github.com/D-Programming-Language, a new > repository called CAPI. > > The CAPI Manifesto > ------------------ > > CAPI is a collection of C header files to publicly available C libraries > and their translations to D. The idea is that if, in C, to interface to a > library > one would write: > > #include "foo.h" > > then the corresponding D code would look like: > > import foo; > > Each C .h file would have a corresponding .d file. Each C directory would > have a corresponding D directory, for example: > > #include "bar/foo.h" // C > > import bar.foo; // D > > The top level directory of each library will have two subdirectories: > > C/ > D/ > > and there will be a one-to-one correspondence of files and directory > structure > between them. > > The D import files will be a rote translation of the corresponding C .h > file. > No attempt will be made to fix, improve, or extend the C api. No attempt > will > be made to duplicate the C documentation, or replace it in any way. There > will be no unittests. Every effort will be made to avoid needing any D > specific > binary files. > > When an updated version of the C header files becomes available, those will > get checked into the C subdirectory tree, and then the corresponding D files > will get updated. > > Version tags used must match the version tags used by the C API files. > > The license used for the D versions should match the C ones, as they are a > derived work. >