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?
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>.
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. (Which CMT maintainers are struggling today, because the library they are maintaining has C++03 support? The CMT is voluntary, and they should be encouraged to focus their time on projects they want to work on in Boost, and let users who care about the unsupported libraries to step up and volunteer to maintain them.) Glen