Would be nice if you could forward the dtor argument here, so it doesn't get lost when `delete` is called from C++ and the base class is also in C++ and handles it as expected.

I don't think it can work so easily (AFAIU you are adding a parameter with a default value so it can still be called without arguments). This helps for explicit calls, but not for the dtor written to the TypeInfo. The latter needs a shim that adds the default value as an argument. Here's an example that calls the dtor this way: ``` import core.stdc.stdio; extern(C++) struct S { int x; ~this() { printf("~S %x\n", x); } } void main() { S[] arr = new S[3]; arr[1].x = 1; arr[2].x = 2; arr.length = 1; assumeSafeAppend(arr); // destroys arr[1] and arr[2] printf("done\n"); } ``` Output is: ``` ~S 2 ~S 1 done ~S 0 ``` Works for Win64, but not for Win32 in dmd 2.080. (Falsely assumes that C++ dtor does not have an argument, though).

When this now works for struct, the documentation should be updated [1]. [1] https://dlang.org/spec/traits.html#getLinkage

How can I also detect if `ad` is an `extern(C++) struct`??

Would be good to test whether C++ and D agree on the position of the dtor in the vtable. Can you add some virtual functions, matching declarations in cppb.cpp and call the dtor from there?

This code can get executed again if semantic was deferred due to forward references (search for `addDeferredSemantic`). Instead of an assert, you could use the state `cppDtorVtblIndex` to avoid duplicate vtbl entries.

A final function can still override a base class implementation. It seems you cannot override non-virtual destructors anyway, so it should also check for the existence of a base class destructor?

This should mention C++, probably even in the member name.

Just FYI, someone might have more better idea here... `dsymbolSemantic` goes all wrong if I give it any hint that this function is virtual/override when it runs. It can't deal with reserved vtable slots like this here. The simplest solution seemed to fix up the relevant state (immediately below) after the function processes as if a normal non-virtual method. I didn't want to mess with the chaos in `dsymbolSemantic` to try and teach it about reserved vtable slots. And that would also add extra state to node structures too... so this hack(-ish) just below... looks okay?

What scope should the C++ global `operator delete` live in? Is there an 'outer scope', or a 'no scope'... some kind of global scope that lives outside the D namespace for special symbols that have no reference? Or is there a way to get to the `object` module from the compiler?

Curly braces on their own lines.

This line.... do I need it? When I step in there, it looks like it's always done it before.

Can this variable be `const`?

Why is `cppDtorVtblIndex` needed, why can't `cldec.dtor.vtblIndex` be used directly?

I'm not sure about the approach in this PR, as I'm not all that familiar with the way vtables are built in D. However, we need to maintain both a C++ and D interface to DMD (unless I'm mistaken both LDC and GDC use the C++ interface). If you're adding a field to `ClassDelcaration`, I think you'll also need to update the same class in `aggregate.h` to keep the C++ interface compatible. cc @ibuclaw and @kinke.