There are a wide range of generic algorithms and utilities built on top of the C++ 14 STL, just like how Boost originally started life. A reasonable cross selection of these generic algorithms are used by Outcome and its unit test suite.
Can you be more specific? What parts of "boost-lite" does Outcome need?
I figured this so easy to calculate I didn't bother listing this, but here you go: ned@lyta:~/windocs/boostish/outcome/test$ g++-6 -MM -Wall -Wextra -std=c++1y -pthread -O3 -DNDEBUG unittests.cpp -lrt -I../include/boost/outcome/v1.0 -I.. -DBOOST_OUTCOME_DISABLE_PREPROCESSED_INTERFACE_FILE unittests.o: unittests.cpp ../include/boost/outcome/outcome.hpp \ ../include/boost/outcome/version.hpp \ ../include/boost/outcome/v1.0/monad.hpp \ ../include/boost/outcome/v1.0/config.hpp \ ../../boost-lite/include/config.hpp \ ../../boost-lite/include/revision.hpp \ ../../boost-lite/include/cpp_feature.h ../../boost-lite/include/import.h \ ../../boost-lite/include/detail/preprocessor_macro_overload.h \ ../include/boost/outcome/v1.0/../revision.hpp \ ../../boost-lite/include/bind/stl11/std/system_error \ ../include/boost/outcome/v1.0/bad_outcome.hpp \ ../include/boost/outcome/v1.0/error_code_extended.hpp \ ../../boost-lite/include/ringbuffer_log.hpp \ ../../boost-lite/include/config.hpp \ ../include/boost/outcome/v1.0/value_storage.hpp \ ../include/boost/outcome/v1.0/detail/value_storage.ipp \ ../../boost-lite/include/tribool.hpp \ ../include/boost/outcome/v1.0/detail/basic_monad.ipp \ ../include/boost/outcome/v1.0/detail/monad_policy.ipp \ ../include/boost/outcome/v1.0/detail/expected_policy.ipp \ ../../boost-lite/include/boost/test/unit_test.hpp \ ../../boost-lite/include/boost/test/../../config.hpp \ ../../boost-lite/include/boost/test/../../console_colours.hpp \ ../../boost-lite/include/boost/test/../../config.hpp \ ../../boost-lite/include/allocator_testing.hpp So, breaking that out: - End user #include of Outcome: - Easily replaceable with Boost.Config and Boost.Preprocessor: ../../boost-lite/include/config.hpp ../../boost-lite/include/revision.hpp ../../boost-lite/include/cpp_feature.h ../../boost-lite/include/import.h ../../boost-lite/include/detail/preprocessor_macro_overload.h - Hard to replace with Boost, would need local copy: ../../boost-lite/include/ringbuffer_log.hpp So this isn't too bad to fall back onto Boost if a boost-lite subrepo is not checked out. - Regression testing Outcome (exceptions enabled): - Easily replaceable with Boost.Test: ../../boost-lite/include/boost/test/unit_test.hpp ../../boost-lite/include/boost/test/../../console_colours.hpp - Hard to replace with Boost, would need local copy: ../../boost-lite/include/allocator_testing.hpp - Regression testing Outcome (exceptions disabled): - Not possible to replace with Boost The exceptions enabled testing is easy to fall back onto Boost with, I intentionally used the exact same macros as Boost.Test does. The exceptions disabled testing I don't think it is possible with Boost, you need boost-lite for that.
Proposed Boost libraries with internal standalone libraries have been reviewed and accepted into Boost in the past. I respectfully suggest
Which internal standalone libraries? Where any of those not reviewed?
Back when I asked about that here I was told that the internal libraries were reviewed as part of the implementation, but not as part of any public API.
I see no point in making concrete statements about how I would lay piping and plumbing. Lots depends on things I don't know answers to yet because the relevant people haven't given me decisions yet, and they won't make those decisions until they know if Outcome is entering Boost or not.
Plumbing is not the issue. The inclusion of an un-reviewed library is.
I must admit to great surprise at how hard people are finding this. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/