outcome v2.1.2 Release NotesRelease Date: 2019-12-18 // over 2 years ago
🚀 v2.1.2 11th December 2019 (Boost 1.72) [release]
👌 Improved compatibility with cmake tooling
📦 : Standalone outcome is now
make install-able, and cmake
find_package()can find it.
📦 Note that you must separately install and
find_package()Outcome's dependency, quickcpplib,
find_package()of Outcome will fail.
0️⃣ Non-permissive parsing is now default in Visual Studio
0️⃣ : The default targets in standalone Outcome's cmake now enable non-permissive parsing.
This was required partially because VS2019 16.3's quite buggy Concepts implementation is
📜 unusuable in permissive parsing mode. Even then, lazy ADL two phase lookup is broken
✅ in VS2019 16.3 with
/std:latest, you may wish to use an earlier language standard.
💥 Breaking change!
: 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.
- Use one of the single header editions.
💥 Breaking change!
: For standalone Outcome, the current compiler is now checked for whether it will compile
code containing C++ Concepts, and if it does, all cmake consumers of Outcome will enable
C++ Concepts. Set the cmake variable
CXX_CONCEPTS_FLAGSto an empty string to prevent
👍 auto detection and enabling of C++ Concepts support occurring.
OUTCOME_TRYoperation now hints to the compiler that operation will be successful
: P1886 Error speed benchmarking 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_TRYpreviously did not hint to the compiler
at all, but now it does. A new suite of macros
OUTCOME_TRY_FAILURE_LIKELYhint to the
compiler that failure is expected. If you wish to return to the previously unhinted
👍 : Support for C++ Coroutines has been added. This comes in two parts, firstly there is
OUTCOME_CO_TRY()operation suitable for performing the
👍 within a C++ Coroutine. Secondly, in the header
lazy<OutcomeType>which let you more
naturally and efficiently use
basic_outcomefrom 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
lazy<T>can accept any
Tas well. Both have been tested and found
working on VS2019 and clang 9.
make_exception_ptr()are now additionally considered for
🚚 compatible copy and move conversions for
basic_result<>. This lets you construct
basic_result<T, E>into a
basic_result<T, error_code>, where
🆓 custom type which has implemented the ADL discovered free function
error_code make_error_code(E), but is otherwise unrelated to
The same availability applies for
👍 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
🐛 Bug fixes:
👍 : The detection of
[[nodiscard]]support in the compiler was very mildly broken.