« Changelog History


outcome v2.1.2 Release Notes

Release Date: 2019-12-18 // over 4 years ago

  • 🚀 v2.1.2 11th December 2019 (Boost 1.72) [release]

    ✨ Enhancements:

    👌 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,
    📦 else 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.

    1. 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_FLAGS to an empty string to prevent
    👍 auto detection and enabling of C++ Concepts support occurring.

    OUTCOME_TRY operation 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_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).

    #199
    👍 : Support for C++ Coroutines has been added. This comes in two parts, firstly there is
    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 eager<OutcomeType> and lazy<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
    ✅ eager<T> and lazy<T> can accept any T as well. Both have been tested and found
    working on VS2019 and clang 9.

    #210
    : make_error_code() and make_exception_ptr() are now additionally considered for
    🚚 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<>.

    🐛 Bug fixes:

    #184
    👍 : The detection of [[nodiscard]] support in the compiler was very mildly broken.