I have also received quite a bit of private email begging me to keep Outcome free of a hard Boost dependency if accepted. I have asked them to say this publicly here, but I would assume they cannot for some reason or other. Quite a few talked about how their multinational's processes would find a standalone Boost.Outcome much much easier to deal with than one with dependency on other Boost libraries. Some of those are household name multinationals, and what they report matches my experience at BlackBerry.
This probably deserves a separate thread. My understanding is that we have three expectations:
1. Boost developers do not want duplication in Boost.
Some Boost developers are ideologically and irrationally attached to "how things are done around here", yes.
I don't know about not wanting duplication in Boost. There is a ton of duplication in Boost. It's been waved through in peer review many times in the past.
This is not true. It was always the idea of Boost to create as little code duplication as possible. Why do you think we have so many cross dependencies between Boost libraries? And yes, it has happened, but it should never have been intentionally waved through.
2. Non-boost users of Outcome do not want a dependncy on Boost.
Actually there is overwhelming evidence that Boost **users** do not want a dependency on Boost. But I've been saying that for years now.
This is just BS, sorry. Boost users choose Boost because they realize that reproducing Boost functionalities would cost them even more than to live with the disadvantages of Boost, namely having to deal with dozens of (partly incompatible) versions, an isolated and arcane build system, insufficient protection from ABI differences between library nmodules which share the same name, ... you name it.
Whilst Outcome is in an unstable state, the actual namespace used is:
namespace boost { namespace outcome { inline namespace v1_GITSHA { ... } } }
This sounds like we are doing a formal review of a library in an unstable state.
Ok, unstable ABI then. Right now I am not promising the ABI won't change. When I do promise that the ABI is written permanently into stone, you'll get your boost::outcome::v1 namespace, and per commit it'll be checked for breaking changes by the abi-compliance-checker.
Again, only half-way true. The _design_ of the whole library is changing under our noses (not just parts of the implementation) while we're supposed to make an educated decision whether this library is ready for Boost or not. Once upon a time a Boost review was supposed to refer to a single fixed source code version and not a moving target as it is for this library. The decision whether somebody would like to see a library accepted into Boost or not should not be based on wishful thinking (that the author will implement things eventually) or on unsubstantiated promises. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu