I was wondering whether C++ interop is already considered sufficiently working enough, as I don't see any plans for improving it in the H1 2017 vision, except for the `C++ stdlib interface` bullet point.

IMO, the main obstacles for mixed D/C++ RAII-style code are:

1) Constructors don't work across the C++/D language barrier, as they are mangled differently and slightly differ in semantics (D ctors assume the instance is pre-initialized with T.init) => currently need to implement them on both sides. Additionally, D structs cannot have a non-disabled parameter-less constructor.
2) Destructors need to be implemented on both sides as well.
3) Copy/move constructors/assignment operators too.

I think D could do a lot better. Constructors for example:

// D
extern(C++) struct T {
  this(bool a); // declares C++ ctor T::T(bool)

  extern(D) this(int a)
  {
    // Generates D ctor T::__ctor(int) and C++ ctor T::T(int).
    // The C++ ctor is implemented as `{ this = T.init; this.__ctor(a); }`
    // to initialize the memory allocated by C++ callers.
    // D clients call the D __ctor directly to avoid double-initialization;
    // that's what the extern(D) makes explicit.
  }
}

// C++
struct T {
  T(bool a) {
    // Callable from D; instance will be initialized twice then.
  }

  T(int a); // declares the C++ ctor wrapper emitted by the D compiler
};

Similarly, the D compiler could generate explicit C++ copy and move constructors automatically if the extern(C++) struct has an extern(D) postblit ctor, so that C++ clients only need to declare them. `extern(C++) this(this);` postblit ctor declarations could be used to make D clients call copy/move ctors implemented in C++ etc...

also: catch D exceptions from C++ vs catching C++ exceptions from D; IIRC only one direction is supported

On Mon, Jan 30, 2017 at 11:42 AM, kinke via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> I was wondering whether C++ interop is already considered sufficiently working enough, as I don't see any plans for improving it in the H1 2017 vision, except for the `C++ stdlib interface` bullet point.
>
> IMO, the main obstacles for mixed D/C++ RAII-style code are:
>
> 1) Constructors don't work across the C++/D language barrier, as they are
> mangled differently and slightly differ in semantics (D ctors assume the
> instance is pre-initialized with T.init) => currently need to implement
> them on both sides. Additionally, D structs cannot have a non-disabled
> parameter-less constructor.
> 2) Destructors need to be implemented on both sides as well.
> 3) Copy/move constructors/assignment operators too.
>
> I think D could do a lot better. Constructors for example:
>
> // D
> extern(C++) struct T {
>   this(bool a); // declares C++ ctor T::T(bool)
>
>   extern(D) this(int a)
>   {
>     // Generates D ctor T::__ctor(int) and C++ ctor T::T(int).
>     // The C++ ctor is implemented as `{ this = T.init; this.__ctor(a); }`
>     // to initialize the memory allocated by C++ callers.
>     // D clients call the D __ctor directly to avoid double-initialization;
>     // that's what the extern(D) makes explicit.
>   }
> }
>
> // C++
> struct T {
>   T(bool a) {
>     // Callable from D; instance will be initialized twice then.
>   }
>
>   T(int a); // declares the C++ ctor wrapper emitted by the D compiler
> };
>
> Similarly, the D compiler could generate explicit C++ copy and move
> constructors automatically if the extern(C++) struct has an extern(D)
> postblit ctor, so that C++ clients only need to declare them. `extern(C++)
> this(this);` postblit ctor declarations could be used to make D clients
> call copy/move ctors implemented in C++ etc...
>