Updating C++ Interop documentation

[IchorDev]

On Monday, 3 July 2023 at 13:41:45 UTC, Sergey wrote:
>
> It seems you already have a good knowledge of what inside this 
> module. Probably you can create a PR with some details. And 
> maybe someone else will join you in documentation update.

I should’ve probably chipped in by now. I’ve used extern(C++) a 
lot and I have a lot of info I could share by now.

Here’s a few notable errors and omissions in the spec and in 
“Interfacing to C++”:


A: The spec fails to provide examples for the string-namespace 
style of extern: `extern(C++, "one", "two")`

B:
> At present, C++ exceptions cannot be caught in or thrown from 
> D, and D exceptions cannot be caught in or thrown from C++.

This is false. D’s spec also begs to differ: 
https://dlang.org/spec/statement.html#catching_cpp_class_objects

C: The spec fails to mention the compiler flag for setting which 
C++ standard to link against.

D:
> D cannot directly call C++ special member functions, and vice 
> versa. These include constructors, destructors, conversion 
> operators, operator overloading, and allocators.

D can call C++ constructors and destructors. Not sure about the 
others.

E: Interfacing to C++ says that using "extern(C++) class" for a 
C++ struct or class is okay. It fails to clarify that C++‘s 
classes are value types, unlike in D where a class instance is 
inherently a pointer, and cannot be made into a value. I’m unsure 
of whether D’s C++ interoperability accounts for this difference, 
or whether this is an omission.

Additionally, D disallows default constructors, but I think when 
they’re extern(C++) they should be allowed just for the sake of 
ease-of-linking. As it is, you can create a constructor with a 
dummy argument and use pragma(mangle) to manually fix it, but 
this is pretty confusing to end-users, where `Type x = Type()` 
isn’t valid code (yet it compiles), but `Type x = Type(0)` is.