If Outcome is accepted in std-flavoured form, I already intend to delete the namespace bindings code entirely. They have only hung around due to this upcoming review.
In that case, what is left of "boost-lite"?
The namespace bindings make up a small part of boost-lite, and as I mentioned, I have been intending to delete them pending this review. 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.
Furthermore, can you describe what you mean by "std-flavoured form"? Does it mean that Outcome is hardwired to
, without support for Boost.System? Are there more differences?
std-flavoured form is the form presented for review. It uses no Boost code. If std-flavoured form is accepted, I would permanently retire any possibility of a boost-flavoured form by deleting the support code in boost-lite.
There is no "taint" from the boost-lite submodule. It can be included into any translation unit without ill effect. It is a good neighbour to all other C++, including different versions of itself.
"boost-lite" is not reviewed by Boost, and therefore not suitable for use in a Boost library, whether as submodule or something else. That is why I am suggesting an alternative.
Proposed Boost libraries with internal standalone libraries have been reviewed and accepted into Boost in the past. I respectfully suggest that people are turning a molehill into a mountain just because git submodules hurt their heads somehow. This stuff is not important, it's just dots on i's and crosses on t's stuff. Plumbing.
You may find a reply to Robert sent recently with a description of one post-approval Boost integration strategy I might take (use boost-lite submodule if checked out, else fall back onto hard Boost dependency).
You may not get approval until this is resolved.
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. For example, if the relevant people don't want Outcome's unit tests to run as part of Boost release testing, then I could give you a very easy answer on plumbing right now. But if they wanted all of the unit testing to run, they would need to accept nearly all of the contents of boost-lite as necessary because Boost.Test won't work with C++ exceptions disabled, and boost-lite's unit test suite uses most of boost-lite's code. So whilst Outcome could be adapted to not use boost-lite, its complete test suite cannot. And that is but one of many decisions to be made by others which is out my control. If the lack of detail on unimportant implementation plumbing is what causes a rejection, then I would find that very unfortunate and short sighted, especially as plumbing does not affect the end user experience. That detail concerns the maintainers, and mostly me, only. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/