D as an extension language for C

[IGotD-]

On Saturday, 13 May 2023 at 18:09:33 UTC, Walter Bright wrote:
>
> D was designed from the beginning to leverage off of existing C 
> code. D's foreign function interface with C is excellent.
>

I thought it was C++ you wanted to leverage.

> But D itself cannot read C .h files nor .c files (a capability 
> that C++ has and has used to great advantage). .h files must be 
> laboriously converted to D. We've done a lot of the usual 
> system .h files conversions, such as core.stdc.stdio, they are 
> in druntime.
>
> The Deimos project is to collect crowd-sourced conversions of C 
> .h files.
>
> The fundamental problem with hand conversions is they are 
> tedious, boring work that nobody wants to do. They also need 
> redoing whenever the vendor of the .h file changes them. As the 
> D community grows, this simply does not scale.
>
> Then there were three attempts at programmatic conversion of .h 
> to .d files, one written by me, one by Jacob, and one by Atila. 
> Those brought us to 3rd base.
>
> To do a home run, the compiler needs to understand C code 
> directly - this is ImportC.
>

You keep mention on this forum that you keep on hitting corner 
cases with importC which s expected. C is old and there many 
quirks, non-standard and compiler specific code out there. I 
would still gone the converter route as it would instead 
translate the .h file to native D which you then can use natively 
within D. For example you haven't enabled C macros to be used 
within D, with a converter you could have converted the macro to 
D code (mixin?). I think that would have scaled better than 
trying to retrofit a C compiler into D compiler. Also why should 
C be a first class citizen and not C++, Rust etc. Since there are 
plenty of languages out there a converter project for each 
language is more convenient.

I'm a bit afraid that importC will be a feature that needs 
constant patching and consume time.