The CAPI Manifesto

[so]

With D being binary compatible with C, i don't know why we worry on such  
things.
Wasn't being able to access C libraries the point? If it wasn't, what is  
the worthwhile point for this constraint?
Wouldn't (sorry for the poor horse) separate compilers solve the most  
problems (if not all) we face on these issues?
C never changes and every compiler vendor have an implementation.

--
import anyapi; // anyapi would be a D module or a C header (anyapi.h...)  
in directory paths.
--

Structs are pod in both languages.
Matching of the standard types is something we can take care of with  
documentation (RTFM)
and with compiler errors generated (when we call functions from the other  
language).

Sorry once again if this should sound stupid or impossible to implement  
(if so, someone please enlighten me), it probably is because everytime we  
open this discussion i feel i am the only one seeing the big picture, the  
potential of D.

On Mon, 17 Oct 2011 05:02:52 +0300, Walter Bright  
<newshound2 at 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.