Can't implicit cast to pointer of bound type?

[d0t2]

It seems you aren't able to implicitly cast types from a source type to a pointer of the target type:

#include "nanobind/nanobind.h"
#include <cstdint>

namespace nb = nanobind;
using namespace nb::literals;

class IntWrapper {
public:
    int64_t i;
    IntWrapper(int64_t i) : i(i) {}
};

NB_MODULE(thing, m) {
    nb::class_<IntWrapper>(m, "IntWrapper").def(nb::init_implicit<int64_t>(), "i"_a);
    m.def("cast_to_value", [](nb::object obj) { return nb::cast<IntWrapper>(obj); }, "obj"_a);
    m.def("cast_to_ptr", [](nb::object obj) { return nb::cast<IntWrapper *>(obj); }, "obj"_a);
}

Running the following test:

import thing

x, y = thing.IntWrapper(1), 1
print(f"cast IntWrapper to value: {x} -> {thing.cast_to_value(x)}")
print(f"cast IntWrapper to ptr: {x} -> {thing.cast_to_ptr(x)}")
print(f"cast int to value: {y} -> {thing.cast_to_value(y)}")
print(f"cast int to ptr: {y} -> {thing.cast_to_ptr(y)}")

Results in this:

cast IntWrapper to value: <thing.IntWrapper object at 0x104fad8f0> -> <thing.IntWrapper object at 0x104faf450>
cast IntWrapper to ptr: <thing.IntWrapper object at 0x104fad8f0> -> <thing.IntWrapper object at 0x104fad8f0>
cast int to value: 1 -> <thing.IntWrapper object at 0x104faf450>
Traceback (most recent call last):
  File ".../test.py", line 7, in <module>
    print(f"cast int to ptr: {y} -> {thing.cast_to_ptr(y)}")
                                     ~~~~~~~~~~~~~~~~~^^^
RuntimeError: std::bad_cast

While an equivalent setup in pybind11:

#include "pybind11/pybind11.h"
#include <cstdint>

namespace py = pybind11;
using namespace py::literals;

class IntWrapper {
public:
    int64_t i;
    IntWrapper(int64_t i) : i(i) {}
};

PYBIND11_MODULE(thing, m) {
    py::class_<IntWrapper>(m, "IntWrapper").def(py::init<int64_t>(), "i"_a);
    py::implicitly_convertible<int64_t, IntWrapper>();
    m.def("cast_to_value", [](py::object obj) { return py::cast<IntWrapper>(obj); }, "obj"_a);
    m.def("cast_to_ptr", [](py::object obj) { return py::cast<IntWrapper *>(obj); }, "obj"_a);
}

seems to work fine:

cast IntWrapper to value: <thing.IntWrapper object at 0x10533ff70> -> <thing.IntWrapper object at 0x104d684f0>
cast IntWrapper to ptr: <thing.IntWrapper object at 0x10533ff70> -> <thing.IntWrapper object at 0x10533ff70>
cast int to value: 1 -> <thing.IntWrapper object at 0x10533fef0>
cast int to ptr: 1 -> <thing.IntWrapper object at 0x104d684f0>

I suppose since you are create a new object, ownership is more ambiguous if you return a pointer, but I don't think that is unique to implicit casting, and pybind11 seems to handle the issue fine? Is there some reason why nanobind can't handle this case? I'm not sure this is necessarily a bug, so I didn't post it under issues. But it should probably be mentioned in the porting guide section of the docs, if it's not fixable.

[wjakob]

This seems scary to me. What does the cast_to_ptr even do in pybind11? I can't imagine that this is safe to rely on.

[d0t2]

For my particular case, it turned out the implicit casting can just be removed (it was brittle and pointless anyway), I'm porting a project from pybind11 to nanobind. So this is no longer a problem for me.

In general though, my guess is that most projects only ever use nb::cast<T*>, i.e. casting to pointers of bound types, there are rarely cases you want to get an actual instance.

So if we want to bind some function that may take in an IntWrapper* or an int implicitly cast into an IntWrapper, we would have to check if (nb::isinstance<IntWrapper>(arg)) { ... } else { ... } and decide either to cast into a pointer or a new instance (to avoid copying when it's not an implicit cast). And that basically defeats the purpose of implicit casting.

I see your point though, it seems implicit_cast is different from other cases where we're receiving a T* from python, since in all other cases T* would already be owned by Python or C++.

Not sure what actually happens in pybind11, understanding the code might be above my pay grade lol. I assume the memory is just leaked, or there's some holder somewhere keeps the pointer alive.