For the reference Rust did consider a similar style of C++ FFI back then [1] [2] [3], but to my knowledge it went nowhere due to the sheer amount of work required and the inability to future-proof. Inline assembly is another similar feature that D is substantially different from Rust, and the rationale for Rust [4] was also similar: D's inline assembly DSL only works in x86 and x86-64.

[1] https://github.com/rust-lang/rust/issues/5853

[2] https://github.com/rust-lang/rfcs/issues/602

[3] https://internals.rust-lang.org/t/better-c-interoperability/...

[4] https://rust-lang.github.io/rfcs/2873-inline-asm.html#implem...

> D's inline assembly DSL only works in x86 and x86-64.

You're conflating DMD (the reference compiler) with the language here. LDC and GDC (the LLVM and GCC based D compilers) both support GCC style "extended" inline assembly[0] and LDC even allows you to write inline LLVM IR.

[0]: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html

I might not have been clear (sorry!) but the DSL here refers to the integrated assembly syntax as opposed to LLVM/GCC's textual approaches. Both syntaxes are officially documented in the D Language Reference [1], which is arguably the specification for D the language, but since DMD came much earlier than other implementations, I think it's fair to consider the DSL to be designed alongside with D. Anyway LDC and GCD's inability to support the DSL strengthens my original point.

[1] https://dlang.org/spec/iasm.html

LDC also supports most of the extended inline asm.

GDC used to support it (long story but that code is now the LDC impl), but it was removed a long time ago. GDC isn't that much younger than dmd.

You're quite right, the D language leaves the inline assembler as implementation defined. DMD has a quite nice assembler that was lifted and updated from the older Digital Mars C++ inline assembler.

Each of the D compilers supports inline assembler for each of the targets the particular compiler supports.

As for the amount of work required, we just rolled up our sleeves and did it :-)

To improve interactivity with C, we even went so far as to build a C compiler into the D compiler. It was officially released this week.

It seems that the C reimplementation is becoming a preferred approach for C FFI in recent languages---at least ones that can afford the cost. Not just D's ImportC but there are other examples like Python cffi. C++ FFI is another story though.

Zig has C++ FFI

Zig's C and C++ FFI is basically based on embedding clang, which seems the only way for its level of FFI in case of C++. For C it is much more doable to make a new C compiler specifically for FFI.

D's ImportC also allows the C code to be extended with D-ish features, like forward references, compile time function execution, and modules.

Can D handle opaque C preprocessor defined types?

yes, if it exists as a thing in the object file you can interoperate with it, with a few exceptions, e.g. diamond inheritance

The C preprocessor does not have types.

But things like `struct S *` with no definition of `S` are handled properly.