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

[Michael Schellenberger Costa via Phabricator via libcxx-commits]

miscco added inline comments.


================
Comment at: libcxx/include/iterator:2498
+
+  // Otherwise, `ranges​::​iter_­move(E)` is ill-formed.
+  void operator()(auto&&) const = delete;
----------------
What is it with those strange `!`


================
Comment at: libcxx/include/iterator:2475
+  // ```
+  template<__unqualified_iter_move _Ip>
+  constexpr decltype(auto) operator()(_Ip&& __i) const
----------------
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


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99873