Re: [boost] Future of C++ and Boost

On Thu, May 5, 2022 at 3:27 PM Mateusz Loskot via Boost wrote:

On Thu, 5 May 2022 at 17:51, James E. King III via Boost wrote:

...

On Thu, May 5, 2022 at 10:59 AM Mateusz Loskot via Boost wrote:

...

On Thu, 5 May 2022 at 16:26, Kostas Savvidis via Boost wrote:

...

[...] In other words, boost needs to shrink not grow.

I mostly agree, but I'd say Boost needs to undergo a restructurisation to remain attractive to all generations of developers, maintainers and users.

I can't see it happen unless we have separate superprojects:

github.com/boostorg/boost (require>=C++17) github.com/boostorg/boost11 (>=C++11 )

and, if still relevant, perhaps:

github.com/boostorg/boost03

As a maintainer, I'd like to be free to maintain a library only for e.g. boostorg/boost and forget about boostorg/boost11, or let new maintainer to take it over there.

About shrinking boost:

I see no reason to have separate superprojects for different language levels. Why not simply have a concerted effort to remove C++03 support?

Why not simply have a concerted effort to remove C++11/14?

Well, we as a community need to make space for everyone, those who want 03, those who want 11, and those who aim higher. Like we did it for those who want Boost.Build and those who want CMake.

Otherwise, we will end up whipping the cream, again, and nothing will happen, again.

I can't see making the space (and making the Boost more inclusive) w/o separate superprojects.

I disagree with you here. Past versions of Boost which are stable and released do support C++03. The work to support the language level has already been done and it is available for all to use. There is no good reason to saddle future development to it. This group as a whole needs to move forward. It is in the same state as I left it in 2018 to start my own company... a lack of consensus to make forward progress. Dropping C++03 and establishing a new baseline, and creating rules for backwards compatibility is what all other projects do. I see no reason for Boost to deviate. If there are people who cannot use C++11 for some reason, they can use older boost releases. We are not leaving anyone behind. They have options. It is up to us to move forward; it is up to them to decide if they also want to move forward. It is not our responsibility to be their savior for all things C++ if they decide not to embrace the future. As a point of comparison, I offer you this: - In Python there is a clear definition when a language level will no longer be supported: https://devguide.python.org/#status-of-python-branches - In node.js there is a clear definition when a language level will no longer be supported: https://nodejs.org/en/about/releases/ - In Ruby there is a clear definition when a language level will no longer be supported: https://endoflife.date/ruby - In Perl there is a clear definition when a language level will no longer be supported: https://endoflife.date/perl Now, you may argue that these are language levels and not libraries. I would counter that Boost is no ordinary library. Given the size and scope of the Boost C++ libraries they are an entire ecosystem unto their own. They deserve the same treatment as a language level. Therefore I would propose, again, that Boost officially adopt the philosophy that it establishes a support baseline of the current C++ language level and the prior three. This is VERY lenient in relation to the other links I posted. This means currently we have C++20 and we will officially support C++17, C++14, and C++11, to the extent a library is not specifically designed for a newer language level than that. I for one would enjoy updating Boost.CI and the 16 Boost libraries that I maintain to stop running C++03 tests through CI and stop claiming support for utterly ancient EOL compilers, as well as language levels. This is a small step forward. We should all consider taking it together. As a community we need to make progress in some capacity. In the past it has been impossible to achieve a consensus on things like this. We need to come together to move forward. In the lens of looking to where Boost will be in 20/50 years from you, this will go a long way to ensuring that the future of Boost is not saddled with impossible backwards compatibility matrices. We had these same discussions 5 years ago and ended up getting nowhere. We cannot let this happen again. - Jim