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.
- 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
- 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.
- 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!
- Separated `result` from its hard coded dependency on the
- 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).
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:
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.