Is it possible to ensure that std::optional<T> arguments always have .none() ?

[MatthiasKohl]

with #include <nanobind/stl/optional.h> it's possible to use std::optional<T> for some type T as arguments to a function.

However, I believe that we still need to specify .none() for those arguments every time, otherwise calling with None leads to a TypeError.

Is there a way we can simply allow None for all optional arguments ? I'm not too familiar with the current implementation, but can this easily be done in a PR ?

[wjakob]

Yeah, it's something that slightly bothered me as well. I cannot think of an elegant way, which is why it probably wasn't part of the original PR #67.

A hacky way to comes in mind would be to add some extra processing to nb_func_new() (which is called whenever we bind a C++ function into the Python world).

For functions with explicit nb::arg values, we would need to do a sweep over descr and mark the associated entry as None-compatible when encountering {Optional[ in the string. For functions that don't have nb::arg values, we would do the same thing but create unnamed arguments on the fly and attach them to the function.

Ideally this processing could be done in a separate function to avoid making nb_func_new even larger. For example, nb_func_process_optional_args or similar.

I would be open to a PR implementing this functionality but won't be able to do it myself. If anybody can think of something better, then that is also interesting.

Ping @yosh-matsuda

[wjakob]

I just committed a small usability improvement that is slightly related to the commit here (in 62a23bb).

When None is used as a default initializer for an argument, the .none() can be omitted. So

nb::arg("arg").none() = nb::none()

becomes

nb::arg("arg") = nb::none()

That said, it doesn't fix the more general case when a default value isn't provided.

[MatthiasKohl]

I think this is quite useful even in my case, so I'm happy if it stays this way for now. It sounds like having the none option automatically would be a bit of a hassle, so I probably won't be able to look into it soon either.