Re: [boost] Boost 2.x - (Was Re: Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*)

Subject: Re: [boost] Boost 2.x - (Was Re: Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*)
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-05-22 15:19:58

On 5/22/2016 2:28 PM, Vicente J. Botet Escriba wrote:
> Le 21/05/2016 à 18:09, Edward Diener a écrit :
>> On 5/21/2016 11:52 AM, Vicente J. Botet Escriba wrote:
>>>
>>> Wether we want a "C++14 only" Boost  version is another thing.
>>
>> What could it possibly achieve to have a Boost with only C++11 or
>> above libraries or a Boost with only C++14 or above libraries, as
>> opposed to having Boost as we have it now in which each library can
>> choose what level of C++ support it requires ? I would really like to
>> get a technical answer, as opposed to an emotional response about
>> "moving forward" and "looking to the future" and "serving the entire
>> C++ community", to that question by those who propose such ideas.
>>
>
> I'm not saying that Boost 1.x must be stopped. Not all the members of
> the Boost community have the same needs. In particular, I could need a
> C++98 Boost version at work, but I would appreciate a C++14 at home. I
> have moved recently to a project using C++11 and Boost. I will comeback
> to you with my experience.
>
> Starting a new Boost version supporting only new compilers has two
> sides: starting a new version and on new compilers.
>
> What I would expect from a new Boost 2.x version?
>
> * That avoids the issues we are facing with the current Boost 1.x version.
>
> Modularity
>
>    * That it is modular
>    * That libraries manage their own version (Major.minor.patch)
>    * That libraries manage the dependencies to other libraries without
>    cycles.
>    * That the included libraries ensure ABI compatibility between minor
>    versions (I don't know how to check this)
>    * That we manage library and point/patch versions.
>
> Delivery
>
>    * That the whole Boost manages their own version also
>    (Major.minor.patch)
>    * That we are able to deliver independently Major, minor and patch
>    versions.
>    * A patch version could consists in upgrading all the libraries to
>    its last patch version respecting the Major and Minor versions and
>    respecting the dependencies.
>    * A minor version would upgrade only the libraries with minor
>    versions and respecting the Major version and the dependencies.
>    * A Major version would upgrade all the libraries respecting the
>    dependencies.
>    * This means that we will need to test 3 new release branches.
>
> * Build
>
>    * That we can build all with CMAKE (as it is a standard de-facto).
>    * Other build systems could be used as well (as far as they can be
>    installed independently)
>
> * Install
>
>    * That we are able to install the libraries independently or as a whole.
>
>
> * Quality
>
>    * That we ensure some quality KPIs. We would make use of anything
>    available to us as static checkers, sanitizers, rules checkers, code
>    coverage, profiling,  ....
>
> * Ownership and evolution
>
>    * That we work as a whole, a library shouldn't be owned only by its
>    initial author. We need to avoid unmaintained libraries.
>    * That any additional features are reviewed to ensure the quality we
>    require.
>
> ...
>
> What I would expect from a new Boost 2.x version requiring C++11, C++14
> or C++1z compiler support?
>
> * don't reinvent the wheel.
> * that it is adapted to the new compiler and library version, e.g. move
> semantics, initializer_list, constexpr, noexcept,  ....
> * that it would help to identify possible issues on the standard, the
> compilers and standard library implementations.
> * that there is a C++ standard proposal that follows the acceptance of a
> library into Boost, either by the author or someone else ... The
> feedback from the Boost reviews is not the same than the feedback from
> the committee.
> * I would appreciate to have the C++14 library additions that don't
> depend on any additional C++14 language feature to be available for
> C++11 compilers in the form of an extension library (we couldn't be able
> to modify classes existing in C++11, but we could add new ones). The
> same applies for C++1z and  C++11/C++14 compilers. This should help as a
> bridge between language versions.
>
> You may have other expectations.
>
> What the authors of such libraries could gain?
> * I guess that supporting less compilers would allow to have a library
> code that has less portability issues and that it is easier to maintain.
> * C++11/14 offers a lot of things that helps to simplify the code "less
> code more software".
> * ...
>
> And last, what the user of such a library could gain?
> * a library that works better with the new standard library
> * able to install the libraries independently
> * less bugs ( remove all the ones related to portability )
> * ...
>
> Maybe it is worth having a new Boost 2.x version for C++98 that respects
> the Boost 2.x expectations (I have no time to work on this).
>
> I repeat myself : whether we want to do it is another question.
> Is it worth doing it? I don't know. It needs a lot of resources and energy.
> What we as a Boost community could lost having additionally these new
> Boost versions?

Many of these are reasonable wishes. But I do not see what having a 
Boost version which supports only C++14 on up compilation has to do with 
any of them. Care to explain what facilities in C++14 on up is going to 
make any of your wishes happen ?