[boost] A possible date for dropping c++03 support

Subject: [boost] A possible date for dropping c++03 support
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-08-28 12:55:48

> -----Original Message-----
> From: Glen Fernandes <glen.fernandes_at_[hidden]>
> Sent: Tuesday, August 28, 2018 7:11 PM
> 
> On Mon, Aug 27, 2018 at 11:56 PM Mike Dev wrote:
> > There are (at least) three problems:
> >
> > 1) Not all dependencies are private. If a library e.g. uses
> >    boost::function in its interface (in particular if it
> >    returns one) the user is also directly affected by changes
> >    to that dependency.
> 
> If the user isn't using the interfaces of library Boost.X which use
> boost::function, but instead using the interfaces of library Boost.X
> that accept std::function, when boost::function changes, yes, library
> Boost.X is affected, but in what way is this painful for you as a
> user?

I was talking about interfaces that only use boost::function instead of
std::function. If you are saying, you use the preprocessor to generate
only one or the other version of an interface depending on the c++ language
version, then this is indeed no real problem for the user, assuming
both versions are tested and all parts of the final program are compiled
with the same c++ version (which - especially on linux - may or may not 
be true). Dependency analysis/management tools will probably still 
think I have a dependency on boost::function though.

> 
> > 2) As you know, the c++ compilation model is incredibly leaky,
> >    meaning transitive dependencies are not hidden from the user.
> >    E.g. if you are using boost core in your header and I include
> >    it, I do get all the symbols (including macros) in my TU too.
> >    Boost has (usually) very good hygiene, so the main problems
> >    here are usually compilation times, [...]
> 
> In my example for this, if library Boost.Y only conditionally includes
> Boost.Core for boost::addressof, (e.g. only if
> BOOST_NO_CXX11_ADDRESSOF is defined) you won't get anything from
> Boost.Core, because for you, there will be no #include of anything
> from Boost.Core. For you, library Boost.Y would only be including
> <memory>.

Same answer as above: you are right, if Boost.Y really completely 
eliminates all direct and indirect dependencies on Boost.Core in 
c++11 then at least compile times should not be effected. 
However, I can tell you that this currently not the common case in
boost. I checked it some time ago for boost::array and there were
at least a dozen (probably dozens - I stopped at some point) libraries
that directly or indirectly included boost.array unconditionally.
And a quick check shows that boost function is also unconditionally
included in at least a few libraries. 
Unfortunately, boostdep is afaik not preprocessor aware - that would make
those kinds of analysis much easier.

> 
> > 3) Not every library in boost is as well maintained as yours
> >    and I as a user prefer "cleaner / simpler" libraries because
> >    they a) tend to have fewer bugs, b) I can more easily modify
> >    things myself if necessary, c) the easier the life of the
> >    maintainer, the more likely he has time to add new
> >    functionalities.
> >    Finally, if boost can deprecate and at some point even remove
> >    some libraries, then their maintainers (in particular the CMT)
> >    can focus their time on different projects.
> 
> Here's what I was trying to understand with my original question: What
> will change if we (Boost) make that announcement tomorrow? It's still
> up to the library maintainer. If Boost.Z maintainer still wants to
> support C++03 because of users that they care about, they will still
> reject your desire for it to use C++11 features unconditionally even
> if it makes the implementation internals of Boost.Z easier to read.

Absolutely, it still depends on the individual library maintainer.
However, if boost would indeed make such announcement that alone would 
be an indicator that at least some maintainers want to make that change,
but probably didn't dare to do it alone. If there is no interest from
the side of the c++03 library maintainers, then this announcement will
never happen. 

The big question is, what happens if most, but not all maintainers are
for it and then actually migrate to c++11. Would the remaining libraries
internalize all their former dependencies to stay c++03 compatible? 

Best 

Mike