2017-05-27 16:40 GMT+02:00 Niall Douglas via Boost
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.
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.
3. Niall does not want to maintain two nearly identical libraries.
I still hold open the offer of a fully Boost flavoured edition of Outcome. I think it a mistake personally, but the offer is there. I've given up on trying to instil awareness of the end user experience of Boost into people on boost-dev.
Mingw is not a regularly tested platform, and hence is not advertised on the documented compiler support page. Last time I tested it was well before Christmas.
Hold on. This is the page you are referring to: https://ned14.github.io/boost.outcome/prerequisites.html
It says:
Outcome is a header only C++ 14 library known to work on these compilers or better:
- clang 3.5 (LLVM) - clang 3.7 (with Microsoft Codegen) - GCC 5.4 - VS2015 Update 2 - Xcode 7.3
It does not mention explicitly that it does not support MinGW. Now, MinGW, according to my knowledge, is not a compiler but a platform on which a compiler works. On MinGW I am using compiler GCC 6.3.0, and this compiler is supported (Or not? -- you are ony mentioning GCC 5.4). This has been always my understanding of what MinGW is.
That's a very fair observation. I have updated develop branch to indicate what compiler-platform combos meant.
It's working on develop branch for me with my mingw-w64, but it's not for you with your version. Problems like these are exactly why I don't support mingw. People ought to use MSVC or winclang on Windows, those work much more reliably. If people really need a POSIX-y environment, Windows can now run Linux binaries very well, even from Win32.
Your decision to simply refuse to support some platform, well.., bothers me. I understand that you do not have access to different compier/platform versions, and that makes looking for bugs quite a burden. But it was my understanding that this is how library maintainance works in Boost. You have the test matrix, where people offer to test your library on compilers/platforms you have never thought of, and you get the required feedback. Can you be persuaded to a conditional agreement: if Outcome gets accepted into Boost, you extend the range of supported compilers.
It costs time and money to support platforms you don't personally use, and I have found an eager approach to deprecating and desupporting open source code I no longer personally use to be the only viable approach for my very limited free time. Once you're been supplying open source to people for twenty years as I have, it's the only feasible attitude to take. It also lets end users either move on to alternatives instead of being strung along waiting for fixes to software I won't be regularly updating any more, or else employ me to fix things for them if their need is urgent.
I aim to support the most common 98% of users in my open source. If others wish to maintain my code on their niche platform/compiler/architecture, I will accept patches from them maintaining that support, and I'll try not to gratuitously break their contributed code. But I won't be doing it myself. I think supporting the top 98% of the most common environments is more than plenty.
That sounds fair.
And I would add that Boost libraries only need to demonstrate a portability requirement. That falls very far short of endless and permanent support of niche, and often broken, toolchains.
Macros other than #include ? Usually you need macros to do things in a different way based on platform, but the precompiled heder does not know what platform it will be used on, so I wonder what macros you mean.
Quite a bit of code is auto generated using preprocessor metaprogramming. All the ABI and namespace versioning stuff, for example.
The partial preprocess step executes all the metaprogramming at build time and I commit to git an expanded edition without the preprocessor metaprogramming. When you #include Outcome, your compiler only needs to preprocess platform specific #if branches. It is very little work to do, and hence runs about a half second quicker.
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.
Will you stabilise v1 in the first official release of official Boost.Outcome. Or in other words, my expectation is that when I download the official Boost release I will be using `boost::outcome::v1`. Do you commit to this?
That way end users, who will tend to return outcomes a lot from public extern functions, will know for a fact that upgrading Outcome does not force a complete rebuild of all shared libraries.