On June 7, 2014 4:01:10 PM EDT, Stephen Kelly
Beman Dawes wrote:
The Boost Steering Committee set the overall policy for Boost library evolution to C++11, C++14, and beyond at its May 2014 meeting in Aspen.
Guidelines to implement that policy are now available at https://svn.boost.org/trac/boost/wiki/BoostEvo
I find that the case study from Jeff Garland leads to the wrong conclusion. The conclusion in the document is that the case study justifies continuing to support old/ancient compilers.
What the case study tells us is that Boost (which version? Let's assume a recent version) helps to migrate from a compiler from the ancient past to a compiler from the very recent past (GCC 4.8). The case study looks to the past.
Actually, it shows that a Boost that doesn't ignore older compilers and versions of the language provides a bridge to newer compilers and versions of the language.
If you want to evolve Boost, then appeal to the use-case of migrating from GCC 4.8 to whatever will be in use 6-10 years from now. That would be looking to the future. Then, thinking mathematically, any migration use-case in the future can be reduced to a previously solved problem plus whatever future Boost does.
There's nothing in the policy that precludes looking forward. Likewise, there's nothing in the policy that requires support for ancient compilers.
The Jeff Garland case study tells us that the past problem is already solved using Boost from the present or the past. You don't need to solve that problem again.
Who was suggesting that?
Solve the present and future problems instead in the evolution of Boost. Put case studies for those in your document instead of the Jeff Garland case study.
Provide an appropriate case study, with discussion of how it should be incorporated in Boost evolution policy, and we'll consider including it. The point of the one included was too illustrate how a Boost 2.0, which breaks from the past completely, is not the way forward. ___ Rob (Sent from my portable computation engine)