: [P1886 *Error speed benchmarking*](https://wg21.link/P1886) showed that there is
considerable gain in very small functions by hinting to the compiler whether the expression
is expected to be successful or not. `OUTCOME_TRY` previously did not hint to the compiler
at all, but now it does. A new suite of macros `OUTCOME_TRY_FAILURE_LIKELY` hint to the
compiler that failure is expected. If you wish to return to the previously unhinted
behaviour, define `OUTCOME_TRY_LIKELY(expr)` to `(!!expr)`.
compatible copy and move conversions for `basic_result<>`. This lets you construct
a `basic_result<T, E>` into a `basic_result<T, error_code>`, where `E` is a
custom type which has implemented the ADL discovered free function
`error_code make_error_code(E)`, but is otherwise unrelated to `error_code`.
The same availability applies for `exception_ptr` with `make_exception_ptr()` being
the ADL discovered free function. `basic_outcome<>` has less support for this than
`basic_result<>` in order to keep constructor count down, but it will accept via
this mechanism conversions from `basic_result<>` and `failure_type<>`.
2019-10-10 18:14:56 +01:00
Niall Douglas (s [underscore] sourceforge {at} nedprod [dot] com)
now an `OUTCOME_CO_TRY()` operation suitable for performing the `TRY` operation from
within a C++ Coroutine. Secondly, in the header `outcome/coroutine_support.hpp` there are
implementations of `awaitable<OutcomeType>` and `task<OutcomeType>` which let you more
naturally and efficiently use `basic_result` or `basic_outcome` from within C++
Coroutines -- specifically, if the result or outcome will construct from an exception
pointer, exceptions thrown in the coroutine return an errored or excepted result with
the thrown exception instead of throwing the exception through the coroutine machinery
(which in current compilers, has a high likelihood of blowing up the program). Both
`awaitable<T>` and `task<T>` can accept any `T` as well. Both have been tested and found
working on VS2019 and clang 9.
2019-10-03 18:35:31 +01:00
Niall Douglas (s [underscore] sourceforge {at} nedprod [dot] com)
The git submodule mechanism used by standalone Outcome of specifying dependent libraries
has been replaced with a cmake superbuild of dependencies mechanism instead. Upon cmake
configure, an internal copy of quickcpplib will be git cloned, built and installed into the
build directory from where an internal `find_package()` uses it. This breaks the use of
the unconfigured Outcome repo as an implementation of Outcome, one must now do one of:
1. Add Outcome as subdirectory to cmake build
2. Use cmake superbuild (i.e. `ExternalProject_Add()`) to build and install Outcome into
a local installation.
3. Use one of the single header editions.
