Subject: Re: [boost] Guidelines to implement Boost library evolution policy (was Boost 2.0)
From: Stephen Kelly (hello_at_[hidden])
Date: 2014-06-08 06:46:31
Rob Stewart wrote:
> On June 8, 2014 5:16:29 AM EDT, Stephen Kelly <hello_at_[hidden]> wrote:
>>Rob Stewart wrote:
>>>>The Jeff Garland case study tells us that the past problem is already
>>>>using Boost from the present or the past. You don't need to solve
>>> Who was suggesting that?
>>The author of the document about the future of Boost currently being
>>From the document:
>>> ... illustrates why Boost continues to support older compilers and
>>> standard libraries
>>And it then illustrates that 'older' means 1996 era compilers.
> As you said, that problem is already solved. There's nothing that must be
> done to solve it. The point is that creating a new version of Boost with
> no support for old platforms does not provide a transition to the brave
> new world of C++11, 14, and beyond.
Migrating to that brave new world requires modularization. Otherwise
foo_library can not bump its compiler requirements unless that's ok for all
of its dependees.
Given the current cyclic dependencies that is a real blocker for everything
in the strongly connected graph. So the current work on removing those
cycles will prove useful to this discussion.
Also, I urge you not to think in terms of language standards. Think in terms
of compiler versions and their features. The year of release of a language
standard is entirely irrelevant. Consider instead what features are
available in the set of minimum compiler requirements you have. It is really
no different to the 'can we use member templates' question.
C++ developers probably won't be able to depend on the existence of
constexpr in portable code before 2020 (ie, until the MSVC release which
supports it is the oldest MSVC version in widespread use). People need to
stop thinking about it as a '2011 feature'.
However, you can rely on the existence of other features such as decltype
and rvalue references whenever MSVC 2010 is the minimum required version
(I'm not saying you need to bump it to that now) and other minimum
requirements also support the relevant features.
So, don't frame questions in your mind as 'can we use C++11?'.
Ask instead 'what are our minimum compiler requirements and what features
can we rely on from them'.
So, what are the current minimum compiler requirements for Boost? Are they
sensible? Would a policy which keeps them 'rolling' make sense? Should a
support for a compiler *ever* be dropped? Robert Ramey seems to think not.
Note that I never suggested a 'big bang' break forward. I suggest only
modernizing your toolchain/compiler/stdlib requirements and then making use
of the features that become available as a result.
It is not clear whether the Boost community wants to do that at all. I get a
lot of emails off-list from people who do want that, but they don't write to
the list so it's quite useless. Others clearly want no dropping of old
If you're creating a document about the future of Boost, compiler/stdlib
versions is what you need to create a concrete policy about. Instead the
document discusses C++11/14 and that's the wrong mindset as I note above.
The language standard is incidental. Think about compiler versions and their
> There's nothing in that policy that requires support for any particular
> old platform.
Is 'particular' the operative word here?
> Add always, library authors and maintainers are free to drop
> support for older platforms add they see fit.
After modularization, to some extent, yes.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk