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

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? If people still are using C++03 then they can use an older release of Boost until they make the transition. Stop testing it, stop saying it works, and allow C++11 in those libraries. The savings to CI time alone would be quite profound. I would like to see the floor move to C++11 at this point. In cases where the standard library has implemented something like what boost delivers in the C++11 standard, then it would also be reasonable to drop those boost libraries because, again, people can use an older release of Boost until they make the transition. If the project regularly claimed support for 3 back-revisions of language then with C++23 is released, C++20, C++17, C++14 would be "officially" supported and C++11 would be dropped. That simply means it is no longer tested or fixes made; people can use an older boost version until they make the transition. Having a hard-and-fast rule like this makes things way more predictable for all of us and all the consumers. About C++ in general (20/50 yrs): In comparison to other languages, C++ package management still seems like it is struggling. I guess you can use conan and cmake together but I haven't done enough to know how easy or difficult it is to do, and it looks like there are platform specific instructions for either. Having worked with python, javascript, perl and rust as well, the package management systems have their warts but generally make it a lot easier to consume external work and release work to others. It is a significant weakness in the ecosystem. - Jim