Re: Dropping C++03 support (again)

From: Robert Ramey (ramey_at_[hidden])
Date: 2023-02-18 21:34:55

On 2/4/23 4:08 AM, Peter Dimov via Boost wrote:
> Greetings,
> 
> I have a novel idea, let's drop C++03 support.
> 

What I don't understand is how we're supporting C++03 now.

 From 
https://pdimov.github.io/articles/phasing_out_cxx03.html#_ongoing_costs_of_maintaining_c03_support

Summary
We need a policy on phasing out C++03 support in Boost.

C++03 support is holding us back. It impedes development, increases 
maintenance costs, increases dependencies, and increases compilation times.

"Library authors and maintainers need to have an approved mechanism for 
dropping C++03 support in their libraries."

Authors and maintainers have never been required to support any version 
of C++ other than the most recently released one.

"I thought library authors were free to only support C++17?"
This is Boost policy for new library submissions. It’s obviously 
unworkable for old and established libraries (that are currently in 
maintenance mode) on which many other libraries depend, both in Boost 
and outside of it."

For the most part C++ versions maintain backward compatibility with 
older versions.  So if a library is accepted while the latest C++ 
version is C++17 and then C++20 comes out, then the library still works 
fine.  So there is nothing to do.

For example, Boost is a dependency of hundreds, if not thousands, Debian 
packages. We have a responsibility to not break them unnecessarily.

"Why not use C++11 only if available?"
In addition to increasing maintenance costs, this also creates other 
problems. Let’s consider the scenario in which a Boost library uses, for 
example, std::function under C++11 and boost::function under C++03.

namespace lib1
{

#if CXX11
using std::function;
#else
using boost::function;
#endif

struct lib1_type
{
     function<void()> f_;
};

} // lib1
It’s common, at least under Linux, for user code to use a 
system-provided Boost (which is often compiled under C++03), and to use 
f.ex. C++14 or even C++17 itself.

This means that lib1_type will have different definitions in the 
precompiled Boost library and in user code, which leads to hard to track 
undefined behavior.

To avoid these problems, lib1 should always use std::function.

Actually to avoid these problems, we should encourage uses to compile 
the boost library from the latest source with the compiler they are 
going to use to build their application.  (aside, they should be 
encouraged to run the test suites of the libraries they are going to use 
as well.

FYI - I'm still conflicted as to whether for some given functionality, I 
should prefer standard library components or the corresponding boost 
components.

Ongoing Costs of Maintaining C++03 Support
Impeded Development

"If a library supports C++03, contributions that use C++11 features have 
to either be rejected, or have C++03 workarounds applied to them."

Currently a the maintainer is permitted to select which of these methods 
is most suitable in a given circumstance.  Nothing more is needed.

"Since C++11 features such as variadic templates and perfect forwarding 
significantly increase productivity, this slows down the pace of 
development."

Productivity for whom?  The library maintainer can now decide whether to 
upgrade to newer components or just do nothing.  Its up to him and fine 
either way.

"Increased Maintenance Costs
Even libraries in maintenance mode need to be updated to support newer 
standards, and C++03 code is significantly costlier to change due to, 
f.ex. use of the preprocessor to emulate variadic templates and use of 
numerous overloads to emulate perfect forwarding."

"Again, currently maintainers can decide among these tradeoffs."

In addition, C++03 compilers are generally older and have more quirks 
and issues that need to be worked around.

Again, currently maintainers can decide among these tradeoffs.

"Increased Dependencies
Libraries that support C++03 have to use Boost components even when a 
corresponding standard library component exists in C++11. Examples are 
std::function, std::bind, std::tuple, std::shared_ptr, <type_traits>, 
std::fpclassify, and so on."

I'm conflicted as too whether std components are better than boost 
components.  I don't see the benefit of enforcing either preference on 
library maintainers.

Increased Compilation Times
One common complaint against Boost is high compilation times. Nearly all 
such objections can be traced to use of either the preprocessor library 
or Boost.MPL, and the reason is that without variadic templates, a high 
number of overloads or specializations need to be generated and parsed.

Again, currently maintainers can decide among these tradeoffs. 
Compilation time is not a huge problem for boost components except for 
users who don't understand how to properly factor code into source 
files.  Trying to help these people is beyond the reach of our efforts.

"If we require C++11 ..."

We're currently required a recent standard for new libraries.  As far as 
I know, all boost libraries currently meet that standard - even those 
written 20 years ago and haven't had much maintenance.

"Suggested Policy
A library author or maintainer will be allowed to announce that C++03 
support in the library is deprecated."

A library author or maintainer has never been required to support any 
specific version of C++ other than the most recent one.  Such a policy 
is already in place and has never been required.

"This announcement will take the following forms:..."

a) Restate that all boost C++ libraries are required to build and run 
with the latest available version of C++.

b) Terminate testing of Boost libraries with versions of C++ earlier 
than C++14? or whatever.

"A note in the documentation;"

Include restatement/reemphasis of traditional boost policy as stated above.

"A message issued at compilation time if a library header is included in 
C++03 mode."

I don't know what this means.  If a header is included in source file 
being compiled by a compiler set up to compile C++03 ?  or if the source 
code only compiles with C++03?(not much code falls in here), or what?

"The recommended form of the code issuing the message will be ..."

if there is no change in the code that happens to supports C++03 why 
would any message be necessary?

If the code has been changed so that it requires support for a more 
recent compiler version than before, then the following message is 
recommended.

#include <boost/config.hpp>
#include <boost/config/pragma_message.hpp>

#if defined(BOOST_NO_CXX11_VARIADIC_TEMPLATES))
BOOST_PRAGMA_MESSAGE("Compiler support for variadic templates required")
#endif

At least two Boost releases must ship with a deprecation notice whenever
such library changes are made.

=====================================

Reiterating the above action plan:

a) Restate that all boost C++ libraries are required to build and run 
with the latest available version of C++.

b) Terminate testing of Boost libraries with versions of C++ earlier 
than C++14? or whatever.

Just invoke the above two actions right now.  No authority is required 
as they don't represent any change in traditional Boost Policy. This 
will save us a ton of time.

Robert Ramey