[libcxx-commits] [PATCH] D99873: [libcxx] adds `std::ranges::iter_move` and `std::iter_rvalue_reference_t

[Christopher Di Bella via Phabricator via libcxx-commits]

cjdb marked 4 inline comments as done.
cjdb added inline comments.


================
Comment at: libcxx/include/iterator:2475
+  // ```
+  template<__unqualified_iter_move _Ip>
+  constexpr decltype(auto) operator()(_Ip&& __i) const
----------------
miscco wrote:
> tcanens wrote:
> > cjdb wrote:
> > > miscco wrote:
> > > > I am slightly concerned about the number of overloads that are introduced and the instantiation cost, which is quite high on clang right now due to lack of memoization of concepts.
> > > > 
> > > > I would rather put everything in a single `operator()` and then use `if constexpr` to return the right thing.
> > > > 
> > > > That would enable us to simplify the concept definitions, as we do not need to exclude the previous concepts  
> > > > which is quite high on clang right now due to lack of memoization of concepts.
> > > 
> > > How long ago did Clang disable memoisation?
> > > 
> > > > I would rather put everything in a single `operator()` and then use `if constexpr` to return the right thing.
> > > 
> > > I'm aware of this optimisation from GCC Concepts TS days, but I'd like to see evidence that Clang will get a significant performance boost from this too.
> > > It'll also mean that we can't have conditional noexcept, something I'm reluctant to give up.
> > Conditional noexcept is required for conformance since the wording uses expression-equivalent.
> Note that we do have conditional noexcept with MSVC and I believe libstdc++
> 
> You have have a look at the `_Choice` machinery @CaseyCarter build. It is super helpful
I think it would be best to benchmark before adopting a more complex solution in the name of optimisation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99873