Regarding: import "foo.h";

[Brad Roberts]

On 7/17/13 3:52 PM, Walter Bright wrote:
> Over the years, I've given a fair amount of thought to, and talked about it with various people:
>
>     import "foo.h";
>
> or something similar as a way to interface existing C (or even C++) code to D. On the plus side, I
> have a C/C++ front end which could be adapted to do this. On the minus,
>
> 1. there may be various #define's necessary to compile it that would normally be supplied on the
> command line to the C compiler
>
> 2. there are various behavior switches (see the PR for DMD that wants to set the signed'ness of char
> types)
>
> 3. rather few .h files seem to be standard compliant C. They always rely on various compiler extensions
>
> 4. the license would be the same as for the back end
>
> 5. having a C/C++ front end as a "bag on the side" of a D compiler seems like a heavy burden to
> anyone wanting to write a D compiler, besides being a fairly massive maintenance effort as it would
> have to be kept up with the latest C/C++ standards and extensions
>
> Essentially, I think it is impractical, and in the worst case scenario, could actually sink D
> because of the diversion of effort necessary. Instead, any such tool should be a separate tool,
> designed, built, and maintained separately. Perhaps DMD could call it like it calls the linker.

6. the time cost of parsing/semanticing c/c++ is significantly higher than D, making .h importing 
dwarf the rest of the cost of the compilation process

7. .h files are roughly static so translating them on each compilation unit is wasteful, generate 
once as part of the build process and update only as needed.  This is stuff that build processes are 
good at.