GitLab

This adds support for a `py::args_kw_only()` annotation that can be
specified between `py::arg` annotations to indicate that any following
arguments are keyword-only.  This allows you to write:

    m.def("f", [](int a, int b) { /* ... */ },
          py::arg("a"), py::args_kw_only(), py::arg("b"));

and have it work like Python 3's:

    def f(a, *, b):
        # ...

with respect to how `a` and `b` arguments are accepted (that is, `a` can
be positional or by keyword; `b` can only be specified by keyword).

- Not currently supported on PyPy

__init__(self) cannot return values. According to https://stackoverflow.com/questions/2491819/how-to-return-a-value-from-init-in-python __new__(cls) should be used, which works.

This variable is a CMake community standard to set the C++
standard of a build. Document it in favor of the previous variable,
which stays as a legacy flag for existing projects.

https://cmake.org/cmake/help/v3.17/variable/CMAKE_CXX_STANDARD.html

With this change, and cast.h as-is in master, test_tagbased_polymorphic.cpp fails to compile with the error message below.
With the cast.h change in pull/2016, building and testing succeeds.

cd pybind11/build/tests && /usr/bin/c++  -DPYBIND11_TEST_BOOST -DPYBIND11_TEST_EIGEN -Dpybind11_tests_EXPORTS -Ipybind11/include -I/usr/include/python3.7m -isystem /usr/include/eigen3  -Os -DNDEBUG -fPIC -fvisibility=hidden   -std=c++2a -flto -fno-fat-lto-objects -Wall -Wextra -Wconversion -Wcast-qual -Wdeprecated -o CMakeFiles/pybind11_tests.dir/test_tagbased_polymorphic.cpp.o -c pybind11/tests/test_tagbased_polymorphic.cpp
In file included from pybind11/include/pybind11/attr.h:13,
                 from pybind11/include/pybind11/pybind11.h:44,
                 from pybind11/tests/pybind11_tests.h:2,
                 from pybind11/tests/test_tagbased_polymorphic.cpp:10:
pybind11/include/pybind11/cast.h: In instantiation of ‘static ...

Currently user specializations of the form

template <typename itype> struct polymorphic_type_hook<itype, std::enable_if_t<...>> { ... };

will fail if itype is also polymorphic, because the existing specialization will also
be enabled, which leads to 2 equally viable candidates. With this change, user provided
specializations have higher priority than the built in specialization for polymorphic types.

When binding code immediately throws an exception of type
py::error_already_set (e.g. via py::module::import that fails), the
catch block sets an import error as expected. Unfortunately, following
this, the deconstructor of py::error_already_set decides to call
py::detail::get_internals() and set up various internal data structures
of pybind11, which fails given that the error flag is active. The call
stack of this looks as follows:

Py_init_mymodule() -> __cxa_decrement_exception_refcount ->
error_already_set::~error_already_set() ->
gil_scoped_acquire::gil_scoped_acquire() -> detail::get_internals() ->
... -> pybind11::detail::simple_collector() -> uh oh..

The solution is simple: we call detail::get_internals() once before
running any binding code to make sure that the internal data structures
are ready.

This commit introduces the use of C++17-style fold expressions when
casting tuples & the argument lists of functions.

This change can improve performance of the resulting bindings: because
fold expressions have short-circuiting semantics, pybind11 e.g. won't
try to cast the second argument of a function if the first one failed.
This is particularly effective when working with functions that have
many overloads with long argument lists.

* Fix test build in C++20

* Add C++20 char8_t/u8string support

If a debug interpreter is detected, we allow linking with
pythonXX_d.lib under windows.

This reverts commit 819802da.

This reverts commit 61e4f118.

* Add FAQ entry, with code example, for dealing with long functions interruption