On 5/14/17 7:56 AM, Niall Douglas via Boost wrote:
Apparently some years ago they were common enough in submitted new Boost libraries, and indeed some internal sublibraries went on to later become Boost libraries in their own right.
We should proceed here with the Outcome review the same way as it was with those preceding cases. Whatever the precedent is.
(I'm not sure what the exact precedent is, whomever knows for sure please speak, but be aware that most of the dependency on boost-lite is substitutable for Boost proper)
I can't say I know for sure, but I do have some experience with this. While creating the serialization library, I depended on existing boost solutions to the extent possible. MPL, config, spirit and I'm sure a bunch of others I don't remember. Someone else later added file_system and system to the tests. So there is, was and always will be a strong dependency between the serialization library and the rest of boost. Still I needed some stuff that didn't exist: extended_type_info, composable dataflow iterators, BOOST_STRONG_TYPEDEF, singleton, state_saver, BOOST_STATIC_WARNING. I created them as "private libraries" in order to keep the development effort within bounds. It's much easier to build and maintain a library as the composite of 10 smaller otherwise decoupled components than try to understand things as a whole. I also looked forward when some of these "private libraries" might get promoted to being boost libraries in their own right. What actually happened was: a) I tried to put these in boost namespace as they were not really part of the serialization library itself. I caught hell for this from an important booster who is now no longer involved in boost. So I moved them below the serialization namespace. b) a number of these "private libraries" got adopted for general usage such that I get bug reports related to usage outside the serialization library. These include dataflow iterators, strong typedef, and singleton. c) a number just didn't work out - BOOST_STATIC_WARNING could never really be made to work across all platforms. BOOST_STRONG_TYPEDEF fell out of use in the serialization library due to evolution in understanding on my part - but continues to be used. d) a number got supplanted by real boost libraries - though I didn't update the serialization library to use them. Type index is similar to extended type info. We now have a component for dealing with unicode (which hasn't worked for me BTW). We now have boost.ranges which looks to me to replace dataflow iterators One key component doesn't fit the above - boost::utf8_codecvt written by ron garcia many, many years ago. He must have done a good job as it seems to be the only reliable implementation of this much needed facility. This was one of the components I wanted to add to the boost root but was prohibited from doing so. It was shared between several libraries so it wasn't a good idea to put it under serialization. But being in boost detail there was no place for tests - which was pretty important since may standard libraries had quirky behavior in this area. While no one was looking, I snuck in a test somewhere which helped but we're still #including the source into other libraries because utf8_codecvt was never "officially reviewed". This will be an ongoing saga since <codecvt> is now being dropped from the standard for being unreliable - oh well. So that short story describes my experience in this area - I don't know if it explains anything though. Make of it what you will. Robert Ramey