You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#include<functional>structOnlyCopyableFun {
OnlyCopyableFun() = default;
OnlyCopyableFun(const OnlyCopyableFun&) = default;
OnlyCopyableFun(OnlyCopyableFun&&) = delete;
booloperator()(auto) const;
};
intmain() {
OnlyCopyableFun f;
auto nf = std::not_fn(f); // only ill-formed in libc++
}
Feel free to correct me if I've missed something.
Not quite sure why these standard call wrapper factories (std::bind_front, std::bind, etc.) require all argument types to be move-constructible, although the call wrapper produced in the above example is still move-constructible as its underlying type has a copy constructor.
It seems to me that just requiring is_constructible_v<FD, F> is enough, which is what the range adaptor object does.
The text was updated successfully, but these errors were encountered:
@CaseyCarter noted that the Standard (via the "call wrapper" phrase of power that I forgot about) requires not_fn() to produce something that's Cpp17MoveConstructible, so the Mandates on it makes sense and its presence isn't a defect.
N4958 [func.require]/3: "Every call wrapper meets the Cpp17MoveConstructible and Cpp17Destructible requirements. An argument forwarding call wrapper is a call wrapper [...]"
/4: "A perfect forwarding call wrapper is an argument forwarding call wrapper that [...]"
[func.not.fn]/4 "Returns: A perfect forwarding call wrapper"
Therefore, this is an implementation issue where we should be static_asserting explicitly, instead of assuming that the implementation will "naturally diagnose" the requirement which is not the case here.
It seems that
std::not_fn
should reject the following code according to [func.not.fn]:godbolt:
Feel free to correct me if I've missed something.
Not quite sure why these standard call wrapper factories (
std::bind_front
,std::bind
, etc.) require all argument types to be move-constructible, although the call wrapper produced in the above example is still move-constructible as its underlying type has a copy constructor.It seems to me that just requiring
is_constructible_v<FD, F>
is enough, which is what the range adaptor object does.The text was updated successfully, but these errors were encountered: