Will you accept a patch to support GObject-style inheritance?

[virtuald]

In the GObject* (and others, such as QEMU's qdev) type system, C-compatible 'inheritance' is implemented by embedding the parent struct in the child struct:

struct Child {
    Parent object;
    ...
};

One can already implement a polymorphic_type_hook to go from Parent to Child objects, but currently you can't do:

py::class_<Child, Parent> c(m, "Child");

Because it requires std::is_base_of<Child, Parent> to be true, which isn't true for GObject types. Adding an overload for std::is_base_of doesn't address the issue (and is a really bad idea anyways).

I theorize that I can very simply implement support for this by adding an attribute that (1) adds a base with a custom cast mechanism, and (2) marks the instance as non-simple (in the same way that virtual/multiple inheritance is implemented). Likely less than a dozen lines of code. It'd probably look like this:

// user needs to provide their own cast function
Parent *child_to_parent(void * p) {
    return PARENT(reinterpret_cast<Child*>(p));
}

py::class_<Child, py::custom_base<Parent>(&child_to_parent)> c(m, "Child");

@rwgk @Skylion007 if implemented, would you accept this in pybind11? If so, I can put some time into adding proper tests and make a PR once it works. If not, I'll just keep it locally since I'll need it for something.

• *yes, I know GObject already has its own custom python wrappers, but GObject is the most prominent example of this style of type system that I can think of

[rwgk]

Sounds interesting.

Recently I was looking for a way to do something like this:

py::class_<MyException, PyExc_Exception>

but I couldn't find a way in the time I gave it and instead feel back to using embedding (here JIC someone is curious).

What you have in mind, could that also solve this?

Likely less than a dozen lines of code.

If you send a draft PR I'll definitely look. No need to polish or make it work on all platforms, but a minimal test that works on at least one platform seems important.

[virtuald]

See #4247 for an initial go at it.