I dispute all of the above assertions. There is not evidence for them - how could there be as they are not true? And even if they were true, they would in no way be an argument for the library, up ending boost via the inclusion of a single very small and simple library or anything else.
I find it astonishing how threatened some people are by a highly non-intrusive internal implementation library which has no effect on: 1. The end user experience. 2. Any other Boost library. 3. Boost itself. People are making mountains out of molehills. Nobody has given a single technical reason why the presence of that internal implementation library is a technical showstopper to anything except the maintainer's maintenance burden, which is my problem, not yours. I'll accept Bjorn's feedback that its unspecified nature makes it harder to review implementation as part of review, but I genuinely thought people would just run g++ -MM and get on with it.
Although it's implicit in my comments, I'll be explicit about my suggestion:
a) submit outcome in a way that looks like the rest of boost libraries so it would be evaluated by the same criteria that other boost libraries are.
As Jon Kalb mentioned during CppChat only yesterday, there has been a wholesale move away from libraries entering monolithic collections like Boost in favour of people's own github repos where few end users find them. And that has been a negative thing with regard to WG21 standardisation. As I hinted at strongly in my technical description of boost-lite, what's coming next is that libraries will join **multiple** collections of standards aspiring C++ libraries. There are already mini-Boost's popping up, most of them are individual github collections, but it won't be long now - thanks to git and git submodules - that a C++ library will become part of many collections simultaneously. All my libraries have been written to be good neighbours to any other C++, and to be highly flexible for end use cases. It's a huge value add for the burgeoning ecosystem of next generation C++ libraries. People don't want intrusive C++ libraries which **impose** foreign build systems and command line tooling and configuration on end users any more. They want libraries you can drop into your C++ as a git submodule or a single file include and no faffing around needed. That's the future. If Boost is unwilling to accept such good neighbour libraries as Outcome is, then I feel very sorry about that. I have tried very hard to make using Outcome a superb end user experience, and for some reason the techniques I have employed scare some people here. A shame. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/