There appears to be a bug in tl::expected with the usage of coro::sync_wait when the return_type is not trivially moveable. It causes the destructor of the users return_type to be called before the move constructor when calling the coroutine's promise.result() function.
It is worth noting in the coro::task class this exact same method of returning the promise's result is used and works fine, but it doesn't use tl::expected, which likely points to a bug in that library.
To work around this bug having a temporary value in the promise.result() call appears to make the compiler generate two move constructor calls, which is less than idea, but at least the users data isn't destroyed before it is returned.
…lt constructed objects for complex return values
There appears to be a bug in tl::expected with the usage of coro::sync_wait when the return_type is not trivially moveable. It causes the destructor of the users return_type to be called before the move constructor when calling the coroutine's promise.result() function.
It is worth noting in the coro::task class this exact same method of returning the promise's result is used and works fine, but it doesn't use tl::expected, which likely points to a bug in that library.
To work around this bug having a temporary value in the promise.result() call appears to make the compiler generate two move constructor calls, which is less than idea, but at least the users data isn't destroyed before it is returned.
Closes #242