From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-10-10 17:30:48
> Any changes for the Boost-version?
If the changelog says Boost Outcome, it's Boost Outcome only. If it says
Standalone Outcome, it's Standalone Outcome only. If it says Outcome,
> - 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.
> I'll use exceptions instead, I think.
I can see no gain to using anything except Outcome's awaitables if
you're already using Outcome in Coroutines (which quite a few people
are, it was a requested feature add). They're more efficient, and make
your coroutines effectively 100% noexcept apart from the frame
allocation without you having to do anything else.
As it happens, at work I needed Outcome working well with Coroutines,
hence the sudden prioritisation of the implementation, as I was able to
use work time to do it rather than personal time.
eager<T> and lazy<T> also have atomic editions, called atomic_eager<T>
and atomic_lazy<T>. These use an atomic for coroutine completion, and
thus synchronise the coroutine result between threads.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk