El 21/10/2026 a las 0:35, Jason Rice via Boost escribió:

Regarding Boost.Hana, I was given Collaborator status by the original author which I think he implied it as an honorary role. I would be willing to maintain it if he gave explicit permission to do so. The way Boost works, the author/official maintainer is totally entitled to pass the maintenance role to whomever they see fit. So, I suggest you ask Louis Dionne, the decision and transfer procedure are primarly up to him (and only to the community if he's unresponsive). I would be especially interested, if it meant allowing to move to C++26 when reflection arrives. Its interface involves functional programming concepts rooted in category theory which make it interesting and relevant, but compile times can be untenably slow for non-trivial use.

On a more general note, perhaps libraries that would be otherwise removed could be allowed to be updated possibly with breaking changes to require newer versions of the standard so they have value and continued interest from collaborators or potential collaborators.

Generally speaking, authors are free to upgrade the C++ requirements for their libs as they please, and we have prior examples of C++ version bumping with many libraries. Of course, some good judgement is expected, and in particular core libraries many other Boost components depend on are typically dealt with conservatively when it comes to raising the minimum C++ standard required (in the case of Hana, its reverse dependencies are Parser and Yap: https://pdimov.github.io/boostdep-report/develop/hana.html). Some Boost libraries (PFR, Describe, maybe others) are already taking advantage of C++26 reflection when available. "When available" is the key point here: these libraries continue to work on pre-C++26 compilers. Maybe you could explore a similar conditional-support scenario for Hana? Joaquín M López Muñoz