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
>> 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
>>>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk