Fair enough, thanks for the time.
I found a thin D binding to ncurses, and 'fixed' it to work with D2.
If y'all get this up and running, this code will probably be better than starting from scratch.

In any case, I think that CAPI is exactly the type of thing that D needs going forward.
I really hope that CAPI gets good support.

On Mon, Oct 17, 2011 at 12:55 AM, Walter Bright <newshound2@digitalmars.com> wrote:
On 10/16/2011 9:28 PM, Jude Young wrote:
Please excuse my ignorance,
but several types in D do not currently translate well into C.

For example, strings in D are not '\0' terminated, which breaks with C.

This is incorrect. String literals in D are 0 terminated, as in C. C has a convention that strings are 0 terminated, but it isn't part of the core language. In D, you can terminate a string with 0 if you want to, or not.


This is not usually a problem, and it's easy to wrap the function in the
translated header file to automate that particular process.

This would fall under attempting to fix the api, which would be beyond the scope of the library.



It seems that your proposal would disallow this particular example.
The translation code would have to be somewhere, what is the argument against
allowing it?

D access to the C API should be direct, and not include hidden costs like translation layers.



In my (admittedly ignorant) opinion, it seems that allowing the automatic
translation of D types to C types
would fit very well, otherwise you'll have to add them yourself every time you
wish to call C.

C doesn't actually even have a 'string' type.