ImportC + metaprogramming?

[Steven Schveighoffer]

I was just watching Brian's talk on OpenBSD porting to D, and in the 
comments on Youtube, someone asked about how ImportC might help with 
avoiding having to port headers.

His response contained this truth nugget: "IIRC, importC goes directly 
from C source to D AST, so importC would need to gain the ability to 
rewrite its AST back into D source code."

One of the biggest problems with ImportC as everyone knows is the 
preprocessor. One thing that absolutely sucks is if you have something like:

```c
#define foo 42
```

This information is lost forever once you preprocess the file. But you 
can expose this by converting this to an enum! How to do it?

Well, this won't work:

```c
enum foo = foo; // translates to `enum 42 = 42`
```

So you have to come up with a *different* name, and then expose that. 
This really sucks, and I believe projects like dstep translate the thing 
to A D enum, and avoid using the preprocessor at all. But in the world 
of C, there's not an easy way to do this without coming up with some 
horrific naming mangle.

I thought, maybe if you import the C file, then you can introspect 
something from D! But no, there is nothing left to introspect once the c 
preprocessor is done. For actual functions, etc. that would work great, 
but not #defines.

But Brian's statement got me thinking -- what if we allowed just a 
*little bit* of the D camel's nose into the tent? Like some escape that 
could allow the D compiler to actually inject some meta into the AST 
while preprocessing?

What if we had something like a .cm or something file, which is treated 
like C + metaprogramming (e.g. __traits)? Then we can use a specialized 
preprocessor to be part of the compilation step that allows assisting 
with the header "porting".

Is this crazy talk, or does it make any sense?

-Steve