Is pybind11 style trampoline class inheritance viable in nanobind?

[d0t2]

In the pybind11 docs, we're given an example of having inheritance between trampoline classes:
https://pybind11.readthedocs.io/en/latest/advanced/classes.html#combining-virtual-functions-and-inheritance

I tested a toy example in nanobind and it seems to work:

#include <string>
#include "nanobind/nanobind.h"
#include "nanobind/trampoline.h"

namespace nb = nanobind;

class Animal {
public:
    virtual std::string go(int n) = 0;
    virtual std::string name() { return "unknown"; }
};

class Dog : public Animal {
public:
    std::string go(int n) override {
        std::string result;
        for (int i = 0; i < n; ++i)
            result += bark() + " ";
        return result;
    }
    virtual std::string bark() { return "woof!"; }
};

class Husky : public Dog {};

template <class AnimalBase = Animal>
class PyAnimal : public AnimalBase {
    NB_TRAMPOLINE(AnimalBase, 2);
public:
    std::string go(int n) override { NB_OVERRIDE_PURE(go, n); }
    std::string name() override { NB_OVERRIDE(name); }
};

template <class DogBase = Dog>
class PyDog : public PyAnimal<DogBase> {
    NB_TRAMPOLINE(PyAnimal<DogBase>, 2);
public:
    std::string go(int n) override { NB_OVERRIDE(go, n); }
    std::string bark() override { NB_OVERRIDE(bark); }
};

NB_MODULE(albatross_py, m) {
    nb::class_<Animal, PyAnimal<>>(m, "Animal")
        .def(nb::init<>())
        .def("go", &Animal::go)
        .def("name", &Animal::name);
    nb::class_<Dog, PyDog<>>(m, "Dog")
        .def(nb::init<>())
        .def("bark", &Dog::bark);
    nb::class_<Husky>(m, "Husky")
        .def(nb::init<>());
}

However, it seems like this pattern was deliberately left out of the nanobind docs. I'm also not sure how it interacts with the NB_TRAMPOLINE macros.

Is this pattern no longer recommended? Are there any edge case differences between how pybind11/nanobind handles trampoline classes that would break it with a more complicated set up? Would it break how nanobind infers inheritance information?

Note that I am migrating a pybind11 project to nanobind which used this pattern extensively.

Side question: Our current pybind11 project uses trampoline classes to store py::object variables, which seems to work fine right now. Would any differences in nanobind break this?

Edit: looking at the implementation of NB_TRAMPOLINE maybe you should instead do this?

template <class AnimalBase = Animal, size_t TrampolineSize = 2>
class PyAnimal : public AnimalBase {
public:
    NB_TRAMPOLINE(AnimalBase, TrampolineSize);
    std::string go(int n) override { NB_OVERRIDE_PURE(go, n); }
    std::string name() override { NB_OVERRIDE(name); }
};

template <class DogBase = Dog, size_t TrampolineSize = 3>
class PyDog : public PyAnimal<DogBase, TrampolineSize> {
public:
    std::string go(int n) override { NB_OVERRIDE(go, n); }
    std::string bark() override { NB_OVERRIDE(bark); }
};

does this work?

Edit 2: it doesn't work, I don't know why. I tried a few different variants, the error messages make no sense to me.

Edit 3: I think this works? Had to learn about C++ behavior for unqualified names from dependent base class, and shadowing of redeclared class instance variables... Perhaps the NB_TRAMPOLINE macro can be changed to accommodate this pattern?

template <class AnimalBase = Animal>
class PyAnimal : public AnimalBase {
public:
    using NBBase = AnimalBase;
    using AnimalBase::AnimalBase;
    nanobind::detail::trampoline<2> nb_trampoline{ this };
    std::string go(int n) override { NB_OVERRIDE_PURE(go, n); }
    std::string name() override { NB_OVERRIDE(name); }
};

template <class DogBase = Dog>
class PyDog : public PyAnimal<DogBase> {
public:
    using NBBase = DogBase;
    using PyAnimal<DogBase>::PyAnimal;
    nanobind::detail::trampoline<2> nb_trampoline{ this };
    std::string go(int n) override { NB_OVERRIDE(go, n); }
    std::string bark() override { NB_OVERRIDE(bark); }
};

[oremanj]

Unlike pybind11, nanobind stores some data of its own in the trampoline instance (the nb_trampoline member). You should only include the NB_TRAMPOLINE macro in PyAnimal; the extra one in PyDog is going to waste space. This seems to work:

template <class AnimalBase = Animal>
class PyAnimal : public AnimalBase {
protected:
    NB_TRAMPOLINE(AnimalBase, 2);
public:
    std::string go(int n) override { NB_OVERRIDE_PURE(go, n); }
    std::string name() override { NB_OVERRIDE(name); }
};

template <class DogBase = Dog>
class PyDog : public PyAnimal<DogBase> {
    using typename PyAnimal<DogBase>::NBBase;
    using PyAnimal<DogBase>::nb_trampoline;
public:
    std::string go(int n) override { NB_OVERRIDE(go, n); }
    std::string bark() override { NB_OVERRIDE(bark); }
}

You have to expand NB_TRAMPOLINE in the protected section of the base class so that the names it defines are visible to the derived class. Then you have to pull them in with using-declarations in order to be visible to unqualified lookup.

Side question: Our current pybind11 project uses trampoline classes to store py::object variables, which seems to work fine right now. Would any differences in nanobind break this?

This should work fine. The only caveat is that nanobind doesn't support the variety of options pybind11 has for controlling whether constructing a T produces a trampoline instance or not. nanobind will create the trampoline instance if the instantiated type is a Python subclass or if constructing the base instance would be invalid (e.g. because the base is an abstract class), and will create a base instance otherwise.

[d0t2]

Thanks for the response!

If we have a single nb_trampoline in the base class, then its size would need to greater than the total number of overridden functions in all subclasses right? So in PyAnimal we'd want NB_TRAMPOLINE(AnimalBase, 3); to include go, name, and bark?

In my last attempt I redeclare nb_trampoline in PyDog since my understanding is that calls to go and bark would use PyDog::nb_trampoline, while calls to name would use PyAnimal::nb_trampoline. This way the total size of nb_trampoline for PyAnimal instances would be 2, and for PyDog instances it would be 4. My guess is having the size be variable between classes would be efficient?

The only caveat is that nanobind doesn't support the variety of options pybind11 has for controlling whether constructing a T produces a trampoline instance or not. nanobind will create the trampoline instance if the instantiated type is a Python subclass or if constructing the base instance would be invalid (e.g. because the base is an abstract class), and will create a base instance otherwise.

Ah okay, thanks for the heads up, I definitely wouldn't have assumed this otherwise, and it may lead to some pretty subtle bugs.