Binding constructors via factory functions

[oremanj]

The porting guide from pybind11 explains why nanobind doesn't have an equivalent of .def(py::init(<lambda>)):

Unfortunately, the implementation of this feature was quite complex and often required further internal calls to the move or copy constructor.

However, nanobind has something pybind11 didn't have: the ability to depend on C++17 features, including guaranteed copy elision. You can construct a T using a lambda-that-returns-a-T without doing any copies or moves at all, even if T isn't copyable or movable.

I'm wondering whether there might be appetite for accepting a PR that allows nb::class_<T>(...).def(nb::init(<lambda>)), only in those cases where <lambda> returns something that can direct-initialize a T. This would be intended as purely syntactic sugar for the placement-new formula, and would be expected to compile to an equivalent level of efficiency in most cases.

[wjakob]

If this works on all compilers (even MSVC), then I would be open to it (with the usual caveat of acceptance being related to much complexity it adds, and if it adds a compile/runtime cost to code that doesn't use this feature).

If this works, is there still a reason to keep the __new__ style constructor besides compatibility?

[oremanj]

If this works, is there still a reason to keep the __new__ style constructor besides compatibility?

new_ would still be needed for cases where the initialization method returns a pointer. new_ can return by value also, but that does require a move, so we would document that new_ should be preferred only in cases where at least one initializer needs to return by pointer (such as because it's calling a C++ factory function that uses that convention).

[oremanj]

Uploaded in #885, thanks!