Re: [boost] The new Boost 17.0.0

On 11/28/2020 7:28 AM, Paul A Bristow via Boost wrote:

...

-----Original Message----- From: Boost On Behalf Of Emil Dotchevski via Boost Sent: 27 November 2020 23:26 To: Boost Cc: Emil Dotchevski Subject: Re: [boost] The new Boost 17.0.0

Deleting support for C++11 and older versions means breaking user code. Therefore, forking means fracturing of the community. I don't see how this is helpful to the users.

Nearly all of Boost is still C++03 compatible - It is only key or core libraries that have this big and bad effect.

(People using Boost.Math to calculate a probability will still be able to - nothing much has changed).

We have an excellent track record for providing workarounds that keep the old version working where possible, while using macros to allow improvements from using new language features.

Eventually library authors run of out road, and/or patience, and say "enough - I need Cxx-more" but it's a slow and continuous process.

Our continuous progress but keep as much working as possible strategy has worked very well for decades.

The difficulty with our strategy is selling it to potential users who are desperate to be able to tick a box marked 'Cxx-supported'. It gives them a warm feeling, but little in reality.

Somehow we don't seem to be able to sell our strategy.

But if we get to Boost 17, Boost 20 and Boost 23 will soon follow. Won't more Boost 1 (and then 17, 23...) users be frightened off/confused?

I agree with this completely. There is only one other issue which I believe is important for end-users using Boost libraries in relation to the C++ standard level, which is that when end-users compile with a certain C++ standard level they are most likely using in their own code C++ standard libraries at that level while Boost libraries compiled at that same C++ standard level may often be using one or more Boost library equivalents to C++ standard library. The end-user I think has a right to be a bit annoyed at this bifurcation of C++ standard library/Boost library equivalent which must then occur in their code in order to use for them useful Boost libraries. Therefore in this sense, and in this sense only, can I understand a call for Boost to provide a set of libraries which, when compiled at the C++11 ( or above ), only use the equivalent C++ standard libraries. This is not in any way to denigrate the Boost equivalent libraries to various C++ standard libraries, since the Boost equivalent libraries sometimes contain more and/or better features or are better designed than their C++ standard library equivalents. But it is still fairly reasonable to understand that, for some given Boost library which an end-user would find useful in his code, dependence on a Boost library when the equivalent C++ standard library is available, might be a strong negative from the end-users point of view not only based on an added dependency but also based on the complication in the end-user's code.