Roadmap

All version numbers listed here are very approximate.

Targets for (unspecified, soonish):

• Integration of smart_holder into refactored code as optional add-on
  • #include <pybind11/pybind11.h> will only see is_smart_holder_base_tag but not any other smart_holder code.
  • #include <pybind11/smart_holder.h> needed to actually bring in the smart_holder code.
  • refactoring of smart_holder code itself, e.g. trim smart_holder_poc.h into a smaller memory/smart_holder.h, move rest to split out tests/memory/smart_holder_poc.h.

Targets for 2.8:

• Decoupling of unit tests
  • Currently test A cannot run until all tests A-Z are compiled.
    • Blocking in parallel build environments
  • Link time with optimization is currently ~63 seconds (gcc 10.2, -Os -flto).
    • Also very long startup times (>15s seconds) in distributed build environments because of very large .so size in debug mode (~100M).
  • Tricks needed for fast development-test iterations.
  • Fix: minimize use of TEST_SUBMODULE, use only if the submodule feature itself is being tested.
• Systematic refactoring
  • Unit tests must not be modified (with only very rare, narrow exceptions).
  • No change to internals (no exceptions).
  • Refactoring into subdirectories.
  • Existing header files will mostly be shims, provided for backward compatibility.
    • While we're at it: leave nothing considered private in namespace detail.
• Optional precompilation
  • WRT PR #2445: jumping between 2 x the number of files is a permanent tax on development activity and an impediment to continuous refactoring.
  • Keep code together, use #ifndef PYBIND11_USE_PRECOMPILE_MODE.
  • Develop (small-ish) tool to split out .cpp files, integrate with CMake.

Targets for 3.0 / Jan 2022, whichever comes first:

• Drop Python 2.7/3.5

Not on the roadmap (yet?)

• Better MyPy integration
• Better Scikit-build integration (waiting on Scikit-build developments)
• Future of type_caster_base
• Multiple-inheritance overhaul (to fix highly unobvious (to pybind11 users) UB)
  • Porting Boost.Python inheritance code.
  • Will probably be another round of refactoring, much smaller scale, but significant.