Re: The new Boost 17.0.0

From: Edward Diener (eldiener_at_[hidden])
Date: 2020-11-28 16:57:03

On 11/28/2020 7:28 AM, Paul A Bristow via Boost wrote:
>> -----Original Message-----
>> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Emil Dotchevski via Boost
>> Sent: 27 November 2020 23:26
>> To: Boost <boost_at_[hidden]>
>> Cc: Emil Dotchevski <emildotchevski_at_[hidden]>
>> 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.