New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Touching up make_future #1940
Touching up make_future #1940
Conversation
- add overloads for shared_future - make sure make_continuation(future<T>(future<T>) does not create ambiguities - import make_future into namespace hpx - adding test - flyby change: import make_future_void into namespace hpx
// conversion function: T f(U). | ||
template <typename R, typename U, typename Conv, | ||
HPX_CONCEPT_REQUIRES_( | ||
hpx::traits::is_callable<Conv(U)>::value)> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we check if the result of Conv(U)
is convertible to R?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can do that, I was afraid of over-constraining requirements.
@sithhell Your comments have been addressed. |
}; | ||
|
||
template <> | ||
struct make_future_helper<void, void> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't the template specialization on line 951 enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, <void, void>
is ambiguous between <void, T>
and <T, T>
LGTM! |
make_future<T>(future<T>)
does not create ambiguities