• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1+++
2title = "Changelog"
3weight = 80
4+++
5
6---
7## v2.1.4 ??? (Boost 1.74) [[release]](https://github.com/ned14/outcome/releases/tag/v2.1.4)
8
9{{% notice note %}}
10The v2.1 branch is expected to be retired end of 2020, with the v2.2 branch
11becoming the default. You can use the future v2.2 branch now using
12[`better_optimisation`](https://github.com/ned14/outcome/tree/better_optimisation).
13This branch has a number of major breaking changes to Outcome v2.1, see the front page
14for details.
15{{% /notice %}}
16
17### Enhancements:
18
19BREAKING CHANGE `void` results and outcomes no longer default construct types during explicit construction
20: Previously if you explicitly constructed a `result<T>` from a non-errored
21`result<void>`, it default constructed `T`. This was found to cause unhelpful
22surprise, so it has been disabled.
23
24New macro `BOOST_OUTCOME_ENABLE_LEGACY_SUPPORT_FOR`
25: The macro {{% api "BOOST_OUTCOME_ENABLE_LEGACY_SUPPORT_FOR" %}} can be used to
26enable aliasing of older naming and features to newer naming and features when
27using a newer version of Outcome.
28
29Concepts now have snake case style naming instead of camel case style
30: When Outcome was first implemented, it was thought that C++ 20 concepts were
31going to have camel case style. This was changed before the C++ 20 release, and
32Outcome's concepts have been renamed similarly. This won't break any code in
33Outcome v2.1, as compatibility aliases are provided. However code compiled
34against Outcome v2.2 will need to be upgraded, unless `BOOST_OUTCOME_ENABLE_LEGACY_SUPPORT_FOR`
35is set to `210` or lower.
36
37Concepts now live in `BOOST_OUTCOME_V2_NAMESPACE::concepts` namespace
38: Previously concepts lived in the `convert` namespace, now they live in their
39own namespace.
40
41New concepts {{% api "basic_result<T>" %}} and {{% api "basic_outcome<T>" %}} added
42: End users were finding an unhelpful gap in between {{% api "is_basic_result<T>" %}}
43and {{% api "value_or_error<T>" %}} where they wanted a concept that matched
44types which were `basic_result`, but not exactly one of those. Concepts filling
45that gap were added.
46
47Operation `TRY` works differently from Outcome v2.2 onwards
48: This is a severely code breaking change which change the syntax of how one uses
49`BOOST_OUTCOME_TRY()`. A regular expression suitable for upgrading code can be found in
50the list of changes between Outcome v2.1 and v2.2.
51
52### Bug fixes:
53
54[#224](https://github.com/ned14/outcome/issues/224)
55: The clang Apple ships in Xcode 11.4 (currently the latest) has not been patched
56with the fixes to LLVM clang that fix `noexcept(std::is_constructible<T, void>)`
57failing to compile which I originally submitted years ago. So give up waiting on
58Apple to fix their clang, add a workaround to Outcome.
59
60Spare storage could not be used from within no-value policy classes
61: Due to an obvious brain fart when writing the code at the time, the spare storage
62APIs had the wrong prototype which prevented them working from within policy classes.
63Sorry.
64
65Boost.Outcome should now compile with `BOOST_NO_EXCEPTIONS` defined
66: Thanks to Emil, maintainer of Boost.Exception, making a change for me, Boost.Outcome
67should now compile with C++ exceptions globally disabled. You won't be able to use
68`boost::exception_ptr` as it can't be included if C++ exceptions are globally disabled.
69
70---
71## v2.1.3 29th April 2020 (Boost 1.73) [[release]](https://github.com/ned14/outcome/releases/tag/v2.1.3)
72
73### Enhancements:
74
75Performance of Outcome-based code compiled by clang has been greatly improved
76: The previous implementation of Outcome's status bitfield confused clang's
77optimiser, which caused low quality codegen. Unlike most codegen issues, this was
78noticeably in empirical benchmarks of real world code, as was shown by
79[P1886 *Error speed benchmarking*](https://wg21.link/P1886).
80
81    The safe part of the [`better_optimisation`](https://github.com/ned14/outcome/tree/better_optimisation)
82Outcome v2.2.0 future branch was merged to Outcome v2.1.3 which includes a new
83status bitfield implementation. This appears to not confuse clang's optimiser,
84and clang 9 produces code which routinely beats GCC 9's code for various canned
85use cases.
86
87Precompiled headers are automatically enabled on new enough cmake's for standalone Outcome
88: If on cmake 3.16 or later, its new precompiled headers build support is used
89to tell consumers of the `outcome::hl` cmake target to precompile Outcome, **if
90and only if** `PROJECT_IS_DEPENDENCY` is false. `PROJECT_IS_DEPENDENCY` is set
91by Outcome's CMakeLists.txt if it detects that it was included using
92`add_subdirectory()`, so for the vast majority of Outcome end users, the use
93of precompiled headers will NOT be enabled.
94
95    Exported targets do NOT request precompilation of headers, as it is
96assumed that importers of the Outcome cmake targets will configure their own
97precompiled headers which incorporate Outcome.
98
99Installability is now CI tested per commit
100: Due to installability of standalone Outcome (e.g. `make install`) breaking
101itself rather more frequently than is ideal, installability is now tested on CI
102per commit.
103
104Coroutines support has been documented
105: The coroutines support added in v2.1.2 has now been properly documented.
106
107### Bug fixes:
108
109[#214](https://github.com/ned14/outcome/issues/214)
110: Newer Concepts implementing compilers were unhappy with the early check for
111destructibility of `T` and `E`, so removed template constraints, falling back
112to static assert which runs later in the type instantiation sequence.
113
114[#215](https://github.com/ned14/outcome/issues/215)
115: For standalone Outcome, `CMAKE_TOOLCHAIN_FILE` is now passed through during
116dependency superbuild. This should solve build issues for some embedded toolchain
117users.
118
119[#220](https://github.com/ned14/outcome/issues/220)
120: A false positive undefined behaviour sanitiser failure in some use cases of
121Experimental Outcome was worked around to avoid the failure message.
122
123[#221](https://github.com/ned14/outcome/issues/221)
124: Restored compatibility with x86 on Windows, which was failing with link errors.
125It was quite surprising that this bug was not reported sooner, but obviously
126almost nobody is using Outcome with x86 on Windows.
127
128[#223](https://github.com/ned14/outcome/issues/223)
129: Fix a segfault in Debug builds only when cloning a `status_code_ptr` in
130Experimental.Outcome only.
131
132---
133## v2.1.2 11th December 2019 (Boost 1.72) [[release]](https://github.com/ned14/outcome/releases/tag/v2.1.2)
134
135### Enhancements:
136
137Improved compatibility with cmake tooling
138: Standalone outcome is now `make install`-able, and cmake `find_package()` can find it.
139Note that you must separately install and `find_package()` Outcome's dependency, quickcpplib,
140else `find_package()` of Outcome will fail.
141
142Non-permissive parsing is now default in Visual Studio
143: The default targets in standalone Outcome's cmake now enable non-permissive parsing.
144This was required partially because VS2019 16.3's quite buggy Concepts implementation is
145unusuable in permissive parsing mode. Even then, lazy ADL two phase lookup is broken
146in VS2019 16.3 with `/std:latest`, you may wish to use an earlier language standard.
147
148**Breaking change!**
149: The git submodule mechanism used by standalone Outcome of specifying dependent libraries
150has been replaced with a cmake superbuild of dependencies mechanism instead. Upon cmake
151configure, an internal copy of quickcpplib will be git cloned, built and installed into the
152build directory from where an internal `find_package()` uses it. This breaks the use of
153the unconfigured Outcome repo as an implementation of Outcome, one must now do one of:
154 1. Add Outcome as subdirectory to cmake build.
155 2. Use cmake superbuild (i.e. `ExternalProject_Add()`) to build and install Outcome into
156 a local installation.
157 3. Use one of the single header editions.
158
159**Breaking change!**
160: For standalone Outcome, the current compiler is now checked for whether it will compile
161code containing C++ Concepts, and if it does, all cmake consumers of Outcome will enable
162C++ Concepts. Set the cmake variable `BOOST_OUTCOME_C_CONCEPTS_FLAGS` to an empty string to prevent
163auto detection and enabling of C++ Concepts support occurring.
164
165`BOOST_OUTCOME_TRY` operation now hints to the compiler that operation will be successful
166: [P1886 *Error speed benchmarking*](https://wg21.link/P1886) showed that there is
167considerable gain in very small functions by hinting to the compiler whether the expression
168is expected to be successful or not. `BOOST_OUTCOME_TRY` previously did not hint to the compiler
169at all, but now it does. A new suite of macros `BOOST_OUTCOME_TRY_FAILURE_LIKELY` hint to the
170compiler that failure is expected. If you wish to return to the previously unhinted
171behaviour, define `BOOST_OUTCOME_TRY_LIKELY(expr)` to `(!!expr)`.
172
173[#199](https://github.com/ned14/outcome/issues/199)
174: Support for C++ Coroutines has been added. This comes in two parts, firstly there is
175now an `BOOST_OUTCOME_CO_TRY()` operation suitable for performing the `TRY` operation from
176within a C++ Coroutine. Secondly, in the header `outcome/coroutine_support.hpp` there are
177implementations of `eager<OutcomeType>` and `lazy<OutcomeType>` which let you more
178naturally and efficiently use `basic_result` or `basic_outcome` from within C++
179Coroutines -- specifically, if the result or outcome will construct from an exception
180pointer, exceptions thrown in the coroutine return an errored or excepted result with
181the thrown exception instead of throwing the exception through the coroutine machinery
182(which in current compilers, has a high likelihood of blowing up the program). Both
183`eager<T>` and `lazy<T>` can accept any `T` as well. Both have been tested and found
184working on VS2019 and clang 9.
185
186[#210](https://github.com/ned14/outcome/issues/210)
187: `make_error_code()` and `make_exception_ptr()` are now additionally considered for
188compatible copy and move conversions for `basic_result<>`. This lets you construct
189a `basic_result<T, E>` into a `basic_result<T, error_code>`, where `E` is a
190custom type which has implemented the ADL discovered free function
191`error_code make_error_code(E)`, but is otherwise unrelated to `error_code`.
192The same availability applies for `exception_ptr` with `make_exception_ptr()` being
193the ADL discovered free function. `basic_outcome<>` has less support for this than
194`basic_result<>` in order to keep constructor count down, but it will accept via
195this mechanism conversions from `basic_result<>` and `failure_type<>`.
196
197### Bug fixes:
198
199[#184](https://github.com/ned14/outcome/issues/207)
200: The detection of `[[nodiscard]]` support in the compiler was very mildly broken.
201
202---
203## v2.1.1 19th August 2019 (Boost 1.71) [[release]](https://github.com/ned14/outcome/releases/tag/v2.1.1)
204
205### Enhancements:
206
207[#184](https://github.com/ned14/outcome/issues/184)
208: As per request from Boost release managers, relocated `version.hpp` and
209`revision.hpp` into detail, and added the Boost licence boilerplate to the top
210of every source file which was missing one (I think). Also took the opportunity
211to run the licence restamping script over all Outcome, so copyright dates are now
212up to date.
213
214[#185](https://github.com/ned14/outcome/issues/185)
215: Add FAQ item explaining issue #185, and why we will do nothing to
216fix it right now.
217
218[#189](https://github.com/ned14/outcome/issues/189)
219: Refactored the `BOOST_OUTCOME_TRY` implementation to use more clarified
220customisation points capable of accepting very foreign inputs. Removed the
221`std::experimental::expected<T, E>` specialisations, as those are no longer
222necessary. Fixed the documentation for the customisation points which
223previously claimed that they are ADL discovered, which they are not. Added
224a recipe describing how to add in support for foreign input types.
225
226[#183](https://github.com/ned14/outcome/issues/183)
227: Added a separate `motivation/plug_error_code` specifically for Boost.
228
229### Bug fixes:
230
231-
232: `BOOST_OUTCOME_VERSION_MINOR` hadn't been updated to 1.
233
234[#181](https://github.com/ned14/outcome/issues/181)
235: Fix issue #181 where Outcome didn't actually implement the strong swap guarantee,
236despite being documented as doing so.
237
238[#190](https://github.com/ned14/outcome/issues/190)
239: Fix issue #190 in Boost edition where unit test suite was not runnable from
240the Boost release distro.
241
242[#182](https://github.com/ned14/outcome/issues/182)
243: Fix issue #182 where `trait::is_exception_ptr_available<T>` was always true,
244thus causing much weirdness, like not printing diagnostics and trying to feed
245everything to `make_exception_ptr()`.
246
247[#194](https://github.com/ned14/outcome/issues/192)
248: Fix issue #192 where the `std::basic_outcome_failure_exception_from_error()`
249was being defined twice for translation units which combine standalone and
250Boost Outcome's.
251
252---
253## v2.1 12th Apr 2019 (Boost 1.70) [[release]](https://github.com/ned14/outcome/releases/tag/v2.1)
254
255- [#180](https://github.com/ned14/outcome/issues/180)
256    - `success()` and `failure()` now produce types marked `[[nodiscard]]`.
257
258- `include/outcome/outcome.natvis` is now namespace permuted like the rest of
259Outcome, so debugging Outcome based code in Visual Studio should look much
260prettier than before.
261
262- [#162](https://github.com/ned14/outcome/issues/162)
263    - `.has_failure()` was returning false at times when it should have returned true.
264
265- [#152](https://github.com/ned14/outcome/issues/152)
266    - GCC 5 no longer can compile Outcome at all due to [https://stackoverflow.com/questions/45607450/gcc5-nested-variable-template-is-not-a-function-template](https://stackoverflow.com/questions/45607450/gcc5-nested-variable-template-is-not-a-function-template).
267Added explicit version trap for GCC 5 to say it can not work. Note this is not a
268breaking change, GCC 5 was never supported officially in any v2 Outcome.
269
270- [#150](https://github.com/ned14/outcome/issues/150)
271    - **BREAKING CHANGE** `result<T, E>`, `boost_result<T, E>` and `std_result<T, E>`
272no longer implement hard UB on fetching a value from a valueless instance if `E` is
273a UDT, they now fail to compile with a useful error message. If you wish hard UB,
274use `unchecked<T, E>`, `boost_unchecked<T, E>` or `std_unchecked<T, E>` instead.
275
276- [#140](https://github.com/ned14/outcome/issues/140)
277    - Fixed a nasty corner case bug where value type's without a copy constructor
278but with a move constructor would indicate via traits that copy construction
279was available. Thanks to Microsoft's compiler team for reporting this issue.
280
281- Added experimental `status_result` and `status_outcome` based on experimental
282`status_code`.
283
284- Boost edition is now 100% Boost, so defaults for `result` and `outcome` are
285`boost::system::error_code::errc_t` and `boost::exception_ptr`. Moreover,
286the test suite in the Boost edition now exclusively tests the Boost edition.
287One can, of course, freely use the standalone edition with Boost, and the Boost
288edition with `std` types.
289
290- Renamed ADL discovered customisation point `throw_as_system_error_with_payload()`
291to `outcome_throw_as_system_error_with_payload()`.
292
293- [#135](https://github.com/ned14/outcome/issues/135)
294    - Added much clearer compile failure when user tries `result<T, T>` or `outcome`
295    where two or more types are identical. Thanks to Andrzej Krzemieński
296    for suggesting a technique which combines SFINAE correctness with
297    the remaining ability for `result<T, T>` etc to be a valid type, but
298    not constructible.
299
300- [#67](https://github.com/ned14/outcome/issues/67)
301    - Fixed one of the oldest long open bugs in Outcome, that the noexcept
302unit tests failed on OS X for an unknown reason.
303
304- [#115](https://github.com/ned14/outcome/issues/115)
305    - Outcome did not construct correctly from `failure_type`.
306
307- Inexplicably outcome's error + exception constructor had been removed.
308Nobody noticed during the Boost peer review, which is worrying seeing as that
309constructor is needed for one of the main advertised features to Boost!
310
311- [#107](https://github.com/ned14/outcome/issues/107) and [#116](https://github.com/ned14/outcome/issues/116)
312    - `operator==` and `operator!=` now become disabled if the value, error and
313    exception types do not implement the same operator.
314    - Relatedly, both comparison operators simply didn't work right. Fixed.
315
316- [#109](https://github.com/ned14/outcome/issues/109)
317    - `swap()` now has correct `noexcept` calculation and now correctly orders
318    the swaps to be whichever is the throwing swap first.
319
320- Added reference dump of v2.1 ABI so we can check if ABI breakage detection
321works in the next set of changes, plus Travis job to check ABI and API compatibility
322per commit.
323
324- [#124](https://github.com/ned14/outcome/issues/124)
325    - `BOOST_OUTCOME_TRY` is now overloaded and selects `void` or `auto` edition
326    according to input parameter count.
327
328- [#120](https://github.com/ned14/outcome/issues/120)
329    - Fix generation of double underscored temporary variables in
330    `BOOST_OUTCOME_UNIQUE_NAME`, which is UB.
331
332- [#110](https://github.com/ned14/outcome/issues/110)
333    - Separated `result` from its hard coded dependency on the `<system_error>` header.
334    - Renamed `result` and `outcome` to `basic_result` and `basic_outcome`.
335    - Renamed `result.hpp` into `basic_result.hpp`.
336    - Moved `<system_error>` and `<exception>` dependent code into new
337    `std_result.hpp` and `std_outcome.hpp` header files.
338    - Added `boost_result.hpp` and `boost_outcome.hpp` which use Boost.System
339    and Boost.Exception (these are `result.hpp` and `outcome.hpp` in the Boost edition).
340
341---
342## v2.0 18th Jan 2018 [[release]](https://github.com/ned14/outcome/releases/tag/v2.0-boost-peer-review)
343
344- Boost peer review edition. This is what was reviewed.
345- Changelog from v1 can be found in the release notes for this release.
346