Boost logo

Boost :

Subject: Re: [boost] A possible date for dropping c++03 support
From: Edward Diener (eldiener_at_[hidden])
Date: 2018-08-26 05:36:45

On 8/25/2018 10:42 PM, Mike Dev via Boost wrote:
>> -----Original Message-----
>> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Edward Diener via
>> Boost
>> Sent: Sunday, August 26, 2018 7:07 AM
>> On 8/25/2018 1:51 PM, Mike Dev via Boost wrote:
>>> From the discussion about abi compatibility when the Boost.System
>>> library is compiled e.g. in c++03 mode and then included in a
>>> c++11 project or vice
>>> versa
>>> (!topic/boost-developers-
>> archive/EWG5NVOZo_
>>> g)
>>>> When can we drop C++03 support? :D
>>> [...]
>>> What about the first or second release in 2020 ?
>> Please define what is meant by "dropping C++03 support
> For me it means that
> - a contributor can use c++11 language and library features
> (be it the library maintainer or someone else opening a PR
> on Github)

There are libraries which work with C++03 on up. If a contributor
decides to use a C++11 language or library feature with that library it
can no longer work with C++03. I think it should be up to the library
maintainer whether a library no longer works with C++03 or not.
Otherwise any contributor to a library can decide what C++ standard
level that library should support.

> - A user (external or internal) may no longer expect a boost library
> to compile with a compiler not supporting c++11 (and we can have a
> discussion just which compilers that are) or when he tries
> to compile it in c++03 language mode (e.g. -std=c++03)

There are plenty of libraries which need some level of support from
C++11 on up. The user of that library currently expects that such a
library will not work when compiling at the C++03 level. OTOH there are
some libraries that will work with C++03 on up. Are you going to tell a
user that they should no longer expect to work with such a library at
the C++03 level even when it currently works fine at that level ? For
what purpose ?

> Is that definition precise enough?
> What other definition did you have in mind (if any)?

I had no definition in mind. Every time someone speaks of Boost
"dropping C++03 support" it means whatever that person wants it to mean.

> If that is your concern:
> I would certainly not expect that you start ripping out the guts
> of an old, battle proven library and replace everything with c++11
> features just for the fun of it. However, next time a feature is
> added or a bug has to be fixed, you no longer have to restrict
> yourself to c++03.

No library maintainer has to restrict his library to any C++ level.
The usual course when upgrading a C++ level is to tell end-users what
you intend to do, and then eventually do it in some later Boost release.
A new library may be written supporting any C++ standard level that it
wants. There is much encouragement in Boost for developers to use a C++
standard level which is useful for whatever they want their library to
accomplish. No library is forced to maintain backwards compatibility
with the C++03 level if it does not want to do so.

> And maybe, over time, some people will contribute patches that
> simplify / improve a library by replacing some complex c++03 solutions
> with simpler c++11 solutions when applicable.

Anybody is welcome to do that and a some people have already
successfully achieved that goal and had their library accepted into
Boost. Boost does not discourage anyone from creating a better version
of a library using a more modern C++ level and more modern programming

My objection to the usual Boost "dropping C++03 support" is that there
is absolutely no reason for forcing libraries which do support C++03,
while being usable at any higher C++ standard level, to do anything. If
you think that some library which works with C++03 would be better by
using some later C++ standard level feature you can always suggest it
and maybe the maintainer will agree with you. But forcing a library to
use some idiom of a higher C++ standard level when the library itself
has no use for any such an idiom seems pretty foolish to me.

> Best
> Mike

Boost list run by bdawes at, gregod at, cpdaniel at, john at