Does method overload resolution consider base class

[hpkfft]

If a method in a derived class has the wrong argument type, but a method in a base class is suitable, is there a way to indicate that the base class methods should be considered?

For example:

#include <nanobind/nanobind.h>
#include <nanobind/stl/string.h>

struct Animal {
    Animal(const std::string& name) : name(name) {}
    virtual ~Animal() = default;
    void set(const std::string& name_) { name = name_; }  // <---- set("Thor")
    std::string name;
};

enum class ServiceKind { none, guide, hearing, psychiatric };

struct Dog : public Animal {
    Dog(const std::string& name) : Animal(name) {}
    void set(ServiceKind service_) { service = service_; }
    ServiceKind service = ServiceKind::none;
};

namespace nb = nanobind;

NB_MODULE(myextension, m) {
    nb::class_<Animal>(m, "Animal")
        .def(nb::init<const std::string&>())
        .def("set", &Animal::set)                         // <---- set("Thor")
        .def_rw("name", &Animal::name);

    nb::enum_<ServiceKind>(m, "ServiceKind")
        .value("none", ServiceKind::none)
        .value("guide", ServiceKind::guide)
        .value("hearing", ServiceKind::hearing)
        .value("psychiatric", ServiceKind::psychiatric);

    nb::class_<Dog, Animal>(m, "Dog")
        .def(nb::init<const std::string&>())
        .def("set", &Dog::set)
        .def_rw("service", &Dog::service);
}

Python:

>>> d = myextension.Dog("Max")
>>> d.set(myextension.ServiceKind.guide)
>>> d.name
'Max'
>>> d.service
myextension.ServiceKind.guide
>>> d.set("Thor")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: set(): incompatible function arguments. The following argument types are supported:
    1. set(self, arg: myextension.ServiceKind, /) -> None

Invoked with types: myextension.Dog, str

[hpkfft]

I'm not (necessarily) asking for a new feature. I see two ways to get a working example:

1. Change the binding in Animal to .def("setName", &Animal::set). I would guess that, more often than not, this is preferred because it will give the extension a better API. Overloading is often overused.
2. Add using Animal::set; to the C++ class Dog and bind both methods as follows:

        .def("set", nb::overload_cast<const std::string&>(&Dog::set))
        .def("set", nb::overload_cast<ServiceKind>(&Dog::set))

[wjakob]

Overload chains don't really know anything about the classes that they are involved with. So this is a pretty central limitation -- you'll have to redo the bindings of all overloads for such a method in the subclass. In principle, you could try to hack this by adding overloads involving the subclass to the parent class, but this would lead to quite confusing error messages in the case of TypeErrors, and it would also show up in docstrings/Sphinx-generated documentation. Finally, walking through long overload chains has a computational cost that would be universally paid in such a case.