Dear Boost, Two months after you accepted Outcome into Boost, I am pleased to say that I believe that all the known bugs and very substantial source refactoring recommended by the peer review have been implemented (detailed changelog is appended below). What remains is a few months of maturing in real world use as all this severe refactoring needs to be tested outside a test suite, and of course the documentation which I don't intend to start work on until the autumn. The Boost edition has, obviously, received a major upgrade and it is now 100% "Boost native" in that it uses Boost.System and Boost.Exception now. The test suite for the Boost edition exclusively tests the Boost native edition, and it all passes. Outcome (both standalone and Boost editions) now can handle both Boost and std types freely intermixed as you see fit. A new "lite" single header edition exists which drags in virtually no system headers, and is hideously low impact on compile times as a result. ABI and API stability have been dumped to git repo with scripting to check the current library against the frozen dumps. This edition should make the corporate crowd very pleased. Very little should appear to have changed from the outside. Code written for v2.0 ought to, more or less, compile and work as before with v2.1. I would appreciate whatever help the Boost community can give in helping to test this edition. I expect new bugs to have been introduced given the severe source code refactoring, and new dual support for Boost and std as equals. My gratitude in advance. Niall --- ## v2.1 in progress [[project]](https://github.com/ned14/outcome/projects/1) - Boost edition is now 100% Boost, so defaults for `result` and `outcome` are `boost::system::error_code::errc_t` and `boost::exception_ptr`. Moreover, the test suite in the Boost edition now exclusively tests the Boost edition. One can, of course, freely use the standalone edition with Boost, and the Boost edition with `std` types. - Renamed ADL discovered customisation point `throw_as_system_error_with_payload()` to `outcome_throw_as_system_error_with_payload()`. - [#135](https://github.com/ned14/outcome/issues/135) - Added much clearer compile failure when user tries `result<T, T>` or `outcome` where two or more types are identical. Thanks to Andrzej KrzemieĊski for suggesting a technique which combines SFINAE correctness with the remaining ability for `result<T, T>` etc to be a valid type, but not constructible. - [#67](https://github.com/ned14/outcome/issues/67) - Fixed one of the oldest long open bugs in Outcome, that the noexcept unit tests failed on OS X for an unknown reason. - [#115](https://github.com/ned14/outcome/issues/115) - Outcome did not construct correctly from `failure_type`. - Inexplicably outcome's error + exception constructor had been removed. Nobody noticed during the Boost peer review, which is worrying seeing as that constructor is needed for one of the main advertised features to Boost! - [#107](https://github.com/ned14/outcome/issues/107) and [#116](https://github.com/ned14/outcome/issues/116) - `operator==` and `operator!=` now become disabled if the value, error and exception types do not implement the same operator. - Relatedly, both comparison operators simply didn't work right. Fixed. - [#109](https://github.com/ned14/outcome/issues/109) - `swap()` now has correct `noexcept` calculation and now correctly orders the swaps to be whichever is the throwing swap first. - Added reference dump of v2.1 ABI so we can check if ABI breakage detection works in the next set of changes, plus Travis job to check ABI and API compatibility per commit. - [#124](https://github.com/ned14/outcome/issues/124) - `OUTCOME_TRY` is now overloaded and selects `void` or `auto` edition according to input parameter count. - [#120](https://github.com/ned14/outcome/issues/120) - Fix generation of double underscored temporary variables in `OUTCOME_UNIQUE_NAME`, which is UB. - [#110](https://github.com/ned14/outcome/issues/110) - Separated `result` from its hard coded dependency on the `<system_error>` header. - Renamed `result` and `outcome` to `basic_result` and `basic_outcome`. - Renamed `result.hpp` into `basic_result.hpp`. - Moved `<system_error>` and `<exception>` dependent code into new `std_result.hpp` and `std_outcome.hpp` header files. - Added `boost_result.hpp` and `boost_outcome.hpp` which use Boost.System and Boost.Exception (these are `result.hpp` and `outcome.hpp` in the Boost edition). -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Currently at the front of the Rapperswil WG21 meeting, and everybody here keeps asking when will Outcome join Boost, and what will the compatibility be with P0709 Zero-overhead deterministic exceptions: Throwing values? So, just to remind folk, I said a few months ago I am targeting the December 2018 release after a period of maturation. This turned out to be highly wise, as a number of interesting bugs turned up - my thanks to the Microsoft compiler team for finding a particular egregious one recently, and my apologies for my fix to that breaking other things which then also had to get fixed. It happens. I am currently refactoring AFIO, which is proposed as the future C++ standard file i/o library in P1031, to use the SG14 proposed standard error object for P0709 Zero-overhead deterministic exceptions which is detailed in P1028. This refactoring isn't complete yet, but it found a few bugs both in Outcome and in P1028. I hope to have it done soon, and that will be a useful milestone reached. What will the compatibility be between Outcome based code and any potential P0709? People ask this, I assume, because of the similarities and that Outcome comes in experimental P1028 std::error flavour. The answer is that I don't know, I can't even speculate yet. Obviously for every Outcome API written like this: outcome<T, std::error> func(pars) noexcept; ... if it could be rewritten as: T func(pars) throws; ... then it's semantically equivalent, but not source equivalent. But can we come up with some preprocessor macro trickery or whatever that implements the same thing, but in library code? Very hard to say right now. And just because one can do it, doesn't mean one should do it. But we'll keep our eye on this, and if Outcome can easily implement a safe subset of P0709 for existing compilers, I might raise a mini-review here on Boost to debate a proposal. We'll see how it goes. Thanks to everybody for their patience, and don't forget you can use Outcome right now - no need to wait for entry into Boost - in both Boost and standalone flavours. Niall
participants (1)
-
Niall Douglas