bast_cast error on undefined type?

[zhqrbitee]

Hi,
I had a code like below:

tmp.def(
           "__init__",
           [](T *holder, std::optional<T> min, std::optional<T> max) {
              ...
           },
           "minimum"_a = std::nullopt, "maximum"_a = std::nullopt)

It compiles fine, but when I import the library, it gives me a RuntimeError: bast_cast.
After debugging with a debug build, it is because std::nullopt have no type_caster defined, but somehow it still calls the cast function and thus throw a bad_cast error:

1. So could we just error out when compiling?
2. If we must throw a exception at runtime, could we have some switch (e.g. in debug build) to give more diagnosis info, instead of raw bad_cast error?

[wjakob]

You will need to submit a small reproducer, otherwise I can't help you. I suspect that the cause is more complex than the snippet shown here (the default type casters don't call nb::cast).

[zhqrbitee]

@wjakob

Thanks for your quick reply!

Here is the code snapshot to reproduce the issue:

#include "nanobind/nanobind.h"
#include "nanobind/stl/optional.h"

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

struct A{};

NB_MODULE(test_nanobind_bad_cast, m) {
  nb::class_<A>(m, "A")
      .def("__init__", [](A *holder, std::optional<int> min, std::optional<int> max) {
        new (holder) A{};
      }, "minimum"_a = std::nullopt, "maximum"_a = std::nullopt);
}

from test_nanobind_bad_cast import A

a = A()

My environment is: macOS Ventura, Python 3.9.17, with nanobind 1.5.0.

[wjakob]

ah, I get it now—it's the default argument conversion. Can you see if nb::none() instead of std::nullopt fixes it?

[zhqrbitee]

@wjakob

Can you see if nb::none() instead of std::nullopt fixes it?

Yes, this way fixes it.

But my concerned is that similar things (e.g. for another unsupported type) may happens in the future and if so, it is quite hard to locate the error (I have to compile debug mode and step into the codes). This is why I ask:

1. So could we just error out when compiling?
2. If we must throw a exception at runtime, could we have some switch (e.g. in debug build) to give more diagnosis info, instead of raw bad_cast error?