[libcxx-commits] [PATCH] D99044: [libc++] Split out `<__functional_{ops, search}>` from `<functional>`

Zoe Carver via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Mon Mar 22 08:31:37 PDT 2021

zoecarver added inline comments.

Comment at: libcxx/include/concepts:394
 concept invocable = requires(_Fn&& __fn, _Args&&... __args) {
-  _VSTD::invoke(_VSTD::forward<_Fn>(__fn), _VSTD::forward<_Args>(__args)...); // not required to be equality preserving
+  _VSTD::__invoke(static_cast<_Fn&&>(__fn), static_cast<_Args&&>(__args)...); // not required to be equality preserving
Quuxplusone wrote:
> zoecarver wrote:
> > cjdb wrote:
> > > I'm against this change, per my reason in D99041.
> > You can keep using forward that comes from `utility/type_traits`.
> Yeah, and I know libc++ style is generally to use `forward` over `static_cast`; I was just testing the waters here. 😛 (The advantage would be avoiding a couple of function template instantiations every time this concept is used. OTOH maybe that matters only if `__invoke` is also changed to avoid `forward`.)
> I'm not sure if @cjdb's comment refers to worrying about "changes to `invoke` that aren't done through `__invoke`, and so we're blind to the changes", which by now I think Tim Song has put to rest; but anyway I think my path of least resistance here is to eliminate the diffs in `<concepts>` and try that part again separately, maybe after more of @cjdb's patches have landed.
Maybe this isn't the case with `static_cast` vs `forward` because they're so synonymous, but I think the added confusion to someone reading this isn't worth the absolutely minimal gain of one template instantiation (which will likely actually be cached for the use in `__invoke` anyway). 

  rG LLVM Github Monorepo



More information about the libcxx-commits mailing list