$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] A possible date for dropping c++03 support
From: Edward Diener (eldiener_at_[hidden])
Date: 2018-08-27 17:59:44
On 8/27/2018 12:29 PM, Peter Dimov via Boost wrote:
> Glen Fernandes вÑоÑе:
>> Do you have an example of a Boost library author or maintainer that 
>> has refused (either a pull request, or a other feature request) to 
>> leverage C++11+ features (after detecting them with Boost.Config, of 
>> course) to provide some more optimal implementation in their library, 
>> or provide a new feature their library?
>>
>> There are Boost libraries are committed to supporting C++03, but they 
>> also leverage C++11, C++14, C++17 features when available, because 
>> this is what those particular library authors/maintainers are happy to 
>> do. (Myself included: I would not refuse to take advantage of a C++17 
>> feature for C++17 users, while still supporting C++11 for C++11 users).
> 
> Doing this in a header-only library is a recipe for (usually 
> asymptomatic) ODR violations, if the library is used by two translation 
> units with different cxxstd settings, as I pointed out recently.
How many times do you think anyone compiles more than one TU with 
different cxxstd settings ? And how is this ever anything but a user error ?
> 
> But that's not the point, is it? The point is, f.ex. that Boost.Test 
> can't drop C++03 and use rvalue references and std::function in its 
> interface (also something we discussed), because it's Boost Test, which 
> other libraries use in their tests. Since we (Boost) officially support 
> C++03, we run tests with C++03, and Boost.Test has to support C++03.
I do not see technically why Boost Test can not have rvalue references 
and std::function for C++11 users on up while still maintaining an 
interface that C++03. But I understand that such implementing such 
functionality might be a PITA to do. So I am certainly not against 
dropping support for C++03 in Boost Test or even dropping support for 
regression testing or CI testing of libraries at the C++03 level.
> 
> If we (Boost) dropped C++03 support, meaning that we no longer support 
> `b2 install` to work with a C++03 compiler and we no longer run (our 
> own) regression tests under C++03 compilers, Boost.Test, and each and 
> every one of its dependencies would now be free to drop C++03 support.
That is fine with me personally. If it ticks off end-users, that you 
would not be able to create a shared/static Boost library at the C++03 
level, you can answer them <g>.
> 
> In addition, we may start retiring libraries that have a standard 
> equivalent, such as f.ex. boost::function. Or we may not - it'd be up to 
> us to decide. But we would be able to do it if we wanted to. (And of 
> course migrate mpl use to mp11. :-) )
I wonder who wrote mp11 ?
The main problem as always is to put resources where there are needed. I 
am not against Boost saying that we are "dropping support for C++03", if 
we actually explain to end-users what this entails and it actually 
entails something significant so that announcing that Boost is "dropping 
support for C++03" is not just a psychological ploy to get end-user to 
use C++11 on up with Boost.
If we just wanted to use words to encourage Boost end-users to use more 
modern C++ standard levels than C++03 in their code we could write 
something like "We encourage Boost users to use C+11 on up standard 
compiler levels with their compiler as Boost resources go to libraries 
which support those levels and a number of Boost libraries can not be 
used at any lower level." That is much different from saying that "Boost 
is dropping support for C++03" if we do not explain specifically what 
the latter actually means.