Re: [boost] A possible date for dropping c++03 support

Subject: Re: [boost] A possible date for dropping c++03 support
From: Roger Leigh (rleigh_at_[hidden])
Date: 2018-08-28 15:22:21

On 28/08/18 11:29, Mike Dev via Boost wrote:
>> -----Original Message-----
>> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Gavin Lambert via Boost
>> Sent: Tuesday, August 28, 2018 1:34 PM
>>
>> There is a significant difference between "we've never tried it on XX
>> and so we don't support it", and "it used to support XX and now doesn't".
>>
>> You are trying to cite cases of the former but it is actually the
>> latter.  Without further explicit clarification, that invariably means
>> "we have decided to start doing things that do not work in XX", ie. that
>> people can definitely no longer use XX.
> 
> Personally, I don't think this makes it any more difficult for the user to
> understand what is going on. The announcement could be something like
>   
> "Starting from version XX we no longer support c++03"
> 
> And the documentation of any library in XX that is willing to make
> the switch could state something like
>   
> "We no longer support compilation in c++03 mode".
> 
> Irrespective of whether a particular library can still be compiled in c++03
> mode in a particular version, I don't see how this can be interpreted any
> differently than
>   
> "I shouldn't rely on XX working in my c++03 project anymore"
> 
> which is exactly, what it is supposed to mean. Nothing more, nothing less.

[A few comments from an end user.]

In the projects I've maintained, where we already made the transition to 
C++11 and later to C++14, this is exactly what we meant.

Some sub-components might have still functioned with C++03, but we 
ceased to test this worked, and we didn't make any guarantees that we 
wouldn't start using C++11 or 14 features in point releases.

NB.  We specified "C++11" and "C++14" as the subset of C++11 and C++14 
features supported by specific versions of GCC, Clang and MSVC, so it 
was clear what the expectations were, and exactly what we would support, 
to avoid using language or library features which weren't available 
across the board (modulo special-casing with e.g. #ifdefs if 
appropriate).  Example: std::regex was buggy with several GCC releases, 
so boost::regex continued to be used as a fallback.  We never had any 
complaints.

While we had multiple sub-components (much less than Boost though), we 
always specified the minimum version across the entire project rather 
than allowing individual components to specify different requirements. 
This is partly practical--the CI systems we provision have a cost to set 
up and maintain, but also it sets expectations for end users, 
maintainers and contributors and makes it clear what's supported and 
permitted, and what is not.  For a project the size of Boost, it would 
be useful to set this minimum requirement top down across the board.

A comment about C++03 compatibility.  It has a cost, and this is one 
example of it:

 
https://www.reddit.com/r/cpp/comments/99cggw/boostmultiindex_introducing_c17_terse_key/e4nacdt/

This is a discussion about Boost.MultiArray.  I've been running into 
several problems with MPL over the last few years, and it became so 
problematic that I ripped out Boost.Variant and replaced it with 
mpark::variant as a prelude to C++17 std::variant.  The MPL dependency 
was the sole reason for this.

MPL is a huge pain when you need to redefine the container size limits. 
It can interfere with other MPL-using types, and if used in a public 
header can interfere with any other library also using MPL.  It becomes 
a fragile mess which you can make work with horrible hacks to the 
include order for some cases.  But a new Boost release can break it all 
over again if the include order changes.  C++11 variadic templates make 
MPL completely redundant.

Is Boost aiming to be up to date and useful for present needs, or is it 
going to be tied to the past and be second-rate?  What I mean is, 
libraries like Variant and MultiArray are inferior to more modern 
reimplementations which aren't tied to Boost.  It's a shame that the 
Boost implementations have stagnated and aren't best in their class. 
Dropping C++03 would permit them to drop the MPL dependency.

This is not to disparage the maintenance of these Boost components.  The 
rationale behind the current approach is sound, and the effort to 
maintain backward compatibility is commendable.  However, C++11/14 
compilers have become standard, and these compatibility compromises are 
now increasingly a hindrance; the benefit of them becomes moot as they 
become increasingly irrelevant.

Many components could also be updated to use standard language and 
library features, dropping a huge amount of legacy cruft which has real 
negative consequences for end users.

Regarding some of the comments about platform compatibility, I support 
C++11 and 14 on several Ubuntu LTS, CentOS, Clang with Xcode and 
FreeBSD, and MSVC releases.  For CentOS 7 (and 6), as others mentioned, 
we have Devtoolset-7 and EPEL, which provide updated versions compatible 
with the base platform.  Unfortunately, the base platform also includes 
Boost 1.53 which EPEL won't ever update.  So we are stuck with 1.53 for 
the lifetime of CentOS 7 if we wish to be compatible with the base 
platform.  So in practice if Boost > 1.68 drops support for C++03, it 
has zero practical effect due to the existing requirement to use 1.53.

The same applies to all the other platforms which also provide Boost; we 
use the provided version for compatibility unless there's no 
alternative.  BSD ports and MacOS homebrew are usually pretty current. 
On Windows/MSVC we build the latest Boost, but that's not strictly 
required, we could stay behind a release or two and patch if needed.

If I had to support a platform with an older compiler after Boost 
dropped C++03 (or later) compatibility, I would simply build the last 
Boost release supporting that compiler.  While the latest Boost release 
is nice to have, IME it's rarely been the case that it's essential due 
to the need to support several years of Boost versions provided by 
various Linux distributions and other package managers.  If the next 
Boost release required C++11 (or even 17), it wouldn't be the end of the 
world, I would simply continue to use 1.67/1.68.

Kind regards,
Roger