-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Why shouldn't we replace _Ref_fn
with reference_wrapper
?
#4027
Comments
IMO we should not replace |
@CaseyCarter Thanks for explonation! Is this design choice documented anywhere? |
Sadly no. Our implementation documentation practices were nearly non-existent before open sourcing. The team was so small (1-3 maintainers) that everyone either wrote or reviewed every change, so we didn't really need documentation. Let's turn this into a documentation issue, and I'll submit a quick comment change to fix it. |
_Ref_fn
with reference_wrapper
?_Ref_fn
with reference_wrapper
?
_Ref_fn
with reference_wrapper
?_Ref_fn
with reference_wrapper
?
In #4025 there's attemption to strengthen the exception specification of
_Ref_fn::operator()
.Given the standard class template
std::reference_wrapper
is already a invocable wrapper and itsoperator()
has a propagating exception specification (thanks to LWG-3764), it seems OK to replace the uses of_Ref_fn
withreference_wrapper
.Pros:
reference_wrapper
, so we might be able to instantiate less specializations.Cons:
reference_wrapper
is slightly heavier than_Ref_fn
;reference_wrapper
is assignable, which might be unwanted for the internal details of the implementation.The text was updated successfully, but these errors were encountered: