I had a giant misunderstanding of what 'synchronizes with' meant in [futures.async]/p5. This invalidated the current design of async in <future>. This is a new design, based on my new understanding, which has been confirmed on the lwg mailing list. The summary is that ~future() (and ~shared_future()) will block when they are created from within async, and the thread hasn't finished yet. As part of this work I created two new type traits: __invokable<F, Args...>::value and __invoke_of<F, Args...>::type. These are what result_of<F(Args...)> wanted to be when it grew up, but never will be. __invoke_of is carefully crafted so that it can serve as its own enable_if (type doesn't exist if the signature isn't invokable). All of this work is C++11 only.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@131639 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/include/__functional_base b/include/__functional_base
index 22ac947..518c9b7 100644
--- a/include/__functional_base
+++ b/include/__functional_base
@@ -440,7 +440,7 @@
template <class _F, class ..._T>
inline _LIBCPP_INLINE_VISIBILITY
-typename result_of<_F(_T...)>::type
+typename __invoke_of<_F, _T...>::type
__invoke(_F&& __f, _T&& ...__t)
{
return _STD::forward<_F>(__f)(_STD::forward<_T>(__t)...);
@@ -476,7 +476,7 @@
// invoke
template <class... _ArgTypes>
_LIBCPP_INLINE_VISIBILITY
- typename __invoke_return<type&, _ArgTypes...>::type
+ typename __invoke_of<type&, _ArgTypes...>::type
operator() (_ArgTypes&&... __args) const
{
return __invoke(get(), _STD::forward<_ArgTypes>(__args)...);