outcome v2.1.2 Release Notes

Release Date: 2019-12-18 // over 2 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.