On 20/02/2018 08:22, Robert Ramey wrote:
On 2/19/18 10:30 AM, Edward Diener wrote:
The problem with your definition of "dropping support for C++03" is that end-users of Boost libraries need to be told that Boost no longer can guarantee that a library which currently works in C++03 mode will continue to do so.
Hmmm - I'm not aware of any such guarantee. I believe that if I wanted to, I could update the serialization library so that it henceforth it would only work under C++11, 14, or ...
Of course there's no reason I would want to do that - and of course no reason that I should be required to do that - and in any event, there would be no way of enforcing such a requirement.
It hasn't been merged to the "main" site yet, but prior discussion on this topic led to the creation of this section: https://beta.boost.org/development/requirements.html#Backwards_compatibility Part of the API contract of a library is which compilers it can be compiled with, which includes the C++ standard conformance level. Dropping support for older compilers or increasing the minimum conformance level (which also can drop support for older compilers) thus ought to be treated as an API breaking change. Which are not forbidden, but are generally considered bad manners unless there's a clear migration path and time to make that migration. Supporting C++11 in a library (eg. adding move constructors where appropriate) can be done in a manner that still compiles on C++03 compilers, thanks to Boost.Config; although things do get more complex in mixed environments if eg. the C++03 and C++11 layouts of std::string for the same compiler and STL differ. Having said that, I'm personally not opposed to encouraging (but not requiring, since the CMT is overloaded) a C++11 baseline. I do have some projects that (for various reasons) are stuck in MSVC9, but they are also stuck with an older Boost release for similar reasons anyway.