We have the `-H` option to emit a .di file from compilation, which contains modules reduced down to declarations.
I would get a lot more value out of a feature that worked the same way, but emit a `.h` file containing only `extern(C)` and `extern(C++)` declarations.
This would enable us to conveniently write code in D as primary, and link C++ as secondary.
The current tendency, which is "write C++ code first, and then bind/link D as secondary", involves manually writing and maintaining D bindings against existing C++ code.
If there was an option built into the D compiler to emit C headers from D compilation, then the binding effort disappears and creates a pressure to write your code in D first, since the binding effort becomes automated and resolved for you.
This is one such subtle, yet quite substantial opportunity to remove some painful sources of friction, and help nudge people into making the switch; people can measure a tangible value in writing their D code first, because the binding is automated when approached from that direction. We need as many of these sources of gravity as we can muster.
People who write D-first will also have a massive advantage in their binding success rate, in that they will not run into typical extern(C++) binding pain-points, like head-const pointers, or templating on class instance rather than class pointer, which are awkward cases that D has no expressions for.
It would be disappointing for this to be a second pass by a separate tool rather than just working it into the existing .di output flow.
Build times are always a problem, and running a compiler over each module twice feels like a big waste of CI resources when the code is already digested and completely resolved by the compiler, and there's already a path within the compiler that does exactly this task.
Comment #4 by iamthewilsonator — 2019-06-10T04:25:54Z