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
<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.
