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,
it's both.
> - 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.
Niall