[PATCH] [libcxx] LWG2442: call_once() shouldn't DECAY_COPY()

[Agustín Bergé]

================
Comment at: include/mutex:445
@@ -444,3 +444,3 @@
 _LIBCPP_INLINE_VISIBILITY
-void call_once(once_flag&, _Callable);
 
----------------
EricWF wrote:
> This change is being made in order to support non-copyable Callable objects, right? I'm not convinced that always adding const is the correct thing to do. Without the const the new signature won't accept rvalues as input but adding const requires Callable to be const-callable.
> 
> Why not provide two signatures? It's not perfect but I think it is better.
> ```
> void call_once(once_flag&, _Callable&); // accepts non-const lvalues.
> void call_once(once_flag&, _Callable const&); // accepts rvalues and const lvalues.
> ```
> 
> Thoughts?
> 
> 
I initially considered adding a perfectly forwarding non-variadic version when rvalue-refs are supported, and the two overloads you suggest above otherwise. This would add quite a lot of noise (each signature is present thrice). I guestimated const-ref to be enough, but I will add as many overloads and workarounds as you deem necessary.

================
Comment at: test/std/thread/thread.mutex/thread.once/thread.once.callonce/call_once.pass.cpp:160
@@ +159,3 @@
+   // GCC 4.8 complains about the following being private
+public:
+    NonCopyable(const NonCopyable&)
----------------
EricWF wrote:
> That seems like it might indicate a problem. Do you know what is going on here? Are you sure you want to work around this?
If you expand the context a bit you will see that I took it from `MoveOnly` right above, I have not experienced the issue myself.

================
Comment at: test/std/thread/thread.mutex/thread.once/thread.once.callonce/call_once.pass.cpp:224
@@ -206,1 +223,3 @@
     }
+    // check LWG2442: call_once() shouldn't DECAY_COPY()
+    {
----------------
EricWF wrote:
> Could you also add tests for the following:
> 1. We don't copy the function.
> 2. We accept a temporary as a function.
> 3. If given a Function object with `operator()(...) &` and `operator()(...) &&` do we call the correct one depending on the value category of the given functor?
> Could you also add tests for the following:
> We don't copy the function.
> We accept a temporary as a function.

This is already the case, `NonCopyable()` is the function.

> If given a Function object with operator()(...) & and operator()(...) && do we call the correct one depending on the value category of the given functor?

Good idea, will do.

http://reviews.llvm.org/D10191

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/