A patch so that T no longer needs to be default constructible when calling QCoro::waitFor(QCoro::Task<T>). Not claiming that this is the best way to do things, but it worked for me. That said I would appreciate any additional testing. I'm only a light user of the QCoro library.
I ended up duplicating some code logic, because I'm not sure if using std::optional in all cases could decrease performance. Previously a T would always be default constructed, but then RVO should occur when returning the value from detail::waitFor() so no additional copy/move would occur. If the default constructor for T is cheap, this should have been fine.
With using a std::optional<T> though, Ts default constructor is never called, but I don't think RVO can occur anymore with returning its value from detail::waitFor(). I thinkT may be moved to return its value, but this is a corner of C++ I don't have a complete grasp on.
A patch so that
T
no longer needs to be default constructible when callingQCoro::waitFor(QCoro::Task<T>)
. Not claiming that this is the best way to do things, but it worked for me. That said I would appreciate any additional testing. I'm only a light user of the QCoro library.I ended up duplicating some code logic, because I'm not sure if using
std::optional
in all cases could decrease performance. Previously aT
would always be default constructed, but then RVO should occur when returning the value fromdetail::waitFor()
so no additional copy/move would occur. If the default constructor forT
is cheap, this should have been fine.With using a
std::optional<T>
though,T
s default constructor is never called, but I don't think RVO can occur anymore with returning its value fromdetail::waitFor()
. I thinkT
may be moved to return its value, but this is a corner of C++ I don't have a complete grasp on.closes #222