[libcxx-commits] [PATCH] D107785: [libc++] Add the __bind_back and __compose helpers

[Louis Dionne via Phabricator via libcxx-commits]

ldionne added inline comments.


================
Comment at: libcxx/include/__functional/bind_back.h:27
+
+#if _LIBCPP_STD_VER > 17
+
----------------
Quuxplusone wrote:
> ldionne wrote:
> > Quuxplusone wrote:
> > > Could this be `> 11`?
> > > Could it be `> 11` if you used `_VSTD::__invoke` instead of `_VSTD::invoke`?
> > > (Besides just feeling nicer, keeping our dependencies minimal might one day help us clean up old code faster. As soon as we drop support for C++11, the whole `#if` goes away. Whereas if you make it depend on C++20, then we have to keep the `#if` in place for another 9 years until we drop support for C++17.)
> > I would agree because of the "dropping `#if`s faster" story, but I think the benefit of using standard facilities (i.e. `invoke` instead of `__invoke`) outweighs that. WDYT?
> I see cost-but-no-benefit to using `_VSTD::invoke` over `_VSTD::__invoke`. We have `__invoke` precisely //so that// we can use it in places where `invoke` wouldn't have been available until C++17. Also `invoke` is heavier-weight than `__invoke`; we'd rather use `__invoke` than `invoke` throughout the library.
`__perfect_forward` uses `is_invocable`, the wording for `bind_front` uses `std::invoke`, and so does the wording for `bind_back` in the paper. It just feels better to use something that everybody knows the semantics of at first glance (`std::invoke`) over something that might or might not be exactly what you'd expect (you can't know without looking). I think that's the primary reason why I find it easier to understand what's going on when `std::invoke` is used over `__invoke`. IMO, we should strive to use standard APIs when we can and when it makes sense to do that, instead of using internal variants of those.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107785/new/

https://reviews.llvm.org/D107785