Prev Up HomeNext

Changelog

v2.1.3 29th April 2020 (Boost 1.73) [release]
Enhancements:
Bug fixes:
v2.1.2 11th December 2019 (Boost 1.72) [release]
Enhancements:
Bug fixes:
v2.1.1 19th August 2019 (Boost 1.71) [release]
Enhancements:
Bug fixes:
v2.1 12th Apr 2019 (Boost 1.70) [release]
v2.0 18th Jan 2018 [release]

v2.1.3 29th April 2020 (Boost 1.73) [release]

note

The v2.1 branch is expected to be retired end of 2020, with the v2.2 branch becoming the default. You can use the future v2.2 branch now using better_optimisation. This branch has a number of major changes to Outcome v2.1, see the front page for details.

Enhancements:

Performance of Outcome-based code compiled by clang has been greatly improved

The previous implementation of Outcome’s status bitfield confused clang’s optimiser, which caused low quality codegen. Unlike most codegen issues, this was noticeably in empirical benchmarks of real world code, as was shown by P1886 Error speed benchmarking.

The safe part of the better_optimisation Outcome v2.2.0 future branch was merged to Outcome v2.1.3 which includes a new status bitfield implementation. This appears to not confuse clang’s optimiser, and clang 9 produces code which routinely beats GCC 9’s code for various canned use cases.

Precompiled headers are automatically enabled on new enough cmake’s for standalone Outcome

If on cmake 3.16 or later, its new precompiled headers build support is used to tell consumers of the outcome::hl cmake target to precompile Outcome, if and only if PROJECT_IS_DEPENDENCY is false. PROJECT_IS_DEPENDENCY is set by Outcome’s CMakeLists.txt if it detects that it was included using add_subdirectory(), so for the vast majority of Outcome end users, the use of precompiled headers will NOT be enabled.

Exported targets do NOT request precompilation of headers, as it is assumed that importers of the Outcome cmake targets will configure their own precompiled headers which incorporate Outcome.

Installability is now CI tested per commit

Due to installability of standalone Outcome (e.g. make install) breaking itself rather more frequently than is ideal, installability is now tested on CI per commit.

Coroutines support has been documented

The coroutines support added in v2.1.2 has now been properly documented.

Bug fixes:

#214
Newer Concepts implementing compilers were unhappy with the early check for destructibility of T and E, so removed template constraints, falling back to static assert which runs later in the type instantiation sequence.
#215
For standalone Outcome, CMAKE_TOOLCHAIN_FILE is now passed through during dependency superbuild. This should solve build issues for some embedded toolchain users.
#220
A false positive undefined behaviour sanitiser failure in some use cases of Experimental Outcome was worked around to avoid the failure message.
#221
Restored compatibility with x86 on Windows, which was failing with link errors. It was quite surprising that this bug was not reported sooner, but obviously almost nobody is using Outcome with x86 on Windows.

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.
Non-permissive parsing is now default in Visual Studio
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.
  3. 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 BOOST_OUTCOME_C_CONCEPTS_FLAGS to an empty string to prevent auto detection and enabling of C++ Concepts support occurring.
BOOST_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. BOOST_OUTCOME_TRY previously did not hint to the compiler at all, but now it does. A new suite of macros BOOST_OUTCOME_TRY_FAILURE_LIKELY hint to the compiler that failure is expected. If you wish to return to the previously unhinted behaviour, define BOOST_OUTCOME_TRY_LIKELY(expr) to (!!expr).
#199
Support for C++ Coroutines has been added. This comes in two parts, firstly there is now an BOOST_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.

v2.1.1 19th August 2019 (Boost 1.71) [release]

Enhancements:

#184
As per request from Boost release managers, relocated version.hpp and revision.hpp into detail, and added the Boost licence boilerplate to the top of every source file which was missing one (I think). Also took the opportunity to run the licence restamping script over all Outcome, so copyright dates are now up to date.
#185
Add FAQ item explaining issue #185, and why we will do nothing to fix it right now.
#189
Refactored the BOOST_OUTCOME_TRY implementation to use more clarified customisation points capable of accepting very foreign inputs. Removed the std::experimental::expected<T, E> specialisations, as those are no longer necessary. Fixed the documentation for the customisation points which previously claimed that they are ADL discovered, which they are not. Added a recipe describing how to add in support for foreign input types.
#183
Added a separate motivation/plug_error_code specifically for Boost.

Bug fixes:

-
BOOST_OUTCOME_VERSION_MINOR hadn’t been updated to 1.
#181
Fix issue #181 where Outcome didn’t actually implement the strong swap guarantee, despite being documented as doing so.
#190
Fix issue #190 in Boost edition where unit test suite was not runnable from the Boost release distro.
#182
Fix issue #182 where trait::is_exception_ptr_available<T> was always true, thus causing much weirdness, like not printing diagnostics and trying to feed everything to make_exception_ptr().
#194
Fix issue #192 where the std::basic_outcome_failure_exception_from_error() was being defined twice for translation units which combine standalone and Boost Outcome’s.

v2.1 12th Apr 2019 (Boost 1.70) [release]


v2.0 18th Jan 2018 [release]

Last revised: April 07, 2020 at 10:22:38 +0100


Prev Up HomeNext