Handling rvalue function arguments

[rhaschke]

I'm trying to wrap a C++ function that accepts an rvalue argument (std::unique_ptr<T>&&) and consumes it. In the docs it is mentioned that unique_ptrs are not allowed as arguments, because the instance might still be used.
However, when passing the pointer as an rvalue reference, this should work anyway - the holder pointer still exists and re-accessing it in python should throw. That's the way it worked in boost::python at least. There, it was possible to release auto_ptrs. Accessing the python object subsequently, was just throwing:

Python argument types in
    test_move_arg_bp.access(Item)
did not match C++ signature:
    access(Item)

An example illustrating the pybind11 issue and a running boost::python example is available here.

[EricCousineau-TRI]

I believe this may be the same request as #1132 - can you confirm or, if it isn't, clarify?
(My old issue does kinda dive off the deep-end for inheritance too, though)

Is the real motivation here unique_ptr<T>, or do you have non-pointer-types that you want to move too?

[rhaschke]

Is the real motivation here unique_ptr, or do you have non-pointer-types that you want to move too?

Our use case just needs to move unique_ptr<T>. But, to be honest, I don't (anymore) see the difference to rvalue function arguments in general. But I didn't touch this issue for nearly a year now.

[EricCousineau-TRI]

Makes sense in pure C++, but yeah, it's a bit more nuanced with pybind11 and native C++ types:
https://pybind11.readthedocs.io/en/stable/advanced/cast/index.html

To answer some of your questions here:
#2047 (comment)

Why does cast_op<T> [...]

Can't answer that one easily :( I think we may have to mull that over a bit (\cc @YannickJadoul @wjakob)

What is the purpose of registering instances?

This is done to expose native C++ types to Python: https://pybind11.readthedocs.io/en/stable/advanced/cast/overview.html
That then enables functionality like this: https://pybind11.readthedocs.io/en/stable/classes.html
Does that shed some light, or were you looking for more detail?

In general, is there some documentation about the architectural design of pybind11?

AFAIK, just the docs and the docstrings in the comments.
The parts that I find the most helpful:

• https://pybind11.readthedocs.io/en/stable/advanced/cast/index.html
• https://pybind11.readthedocs.io/en/stable/advanced/pycpp/index.html
• https://pybind11.readthedocs.io/en/stable/advanced/smart_ptrs.html

Are you looking for more detail, like design decisions, rationale, etc? If so, the main places I've seen more details are in discussions in issues and PRs thus far.

[YannickJadoul]

Why does cast_op<T> [...]

Can't answer that one easily :( I think we may have to mull that over a bit (\cc @YannickJadoul @wjakob)

A quick look tells me it goes from the type_caster, which basically strips all references and pointers of the type (e.g., MyClass), back to the actual required type (e.g. const MyClass *). But to puzzle everything together again, I'd need to spend some more time, because casters always turn out to be more complex than you had expected. :-/