On 17/07/25 13:25 -0400, Patrick Palka wrote:
On Thu, 17 Jul 2025, Jonathan Wakely wrote:On 17/07/25 11:26 -0400, Patrick Palka wrote: > On Thu, 17 Jul 2025, Tomasz Kamiński wrote: > > + > > +namespace std _GLIBCXX_VISIBILITY(default) > > +{ > > +_GLIBCXX_BEGIN_NAMESPACE_VERSION > > + > > +namespace __detail > > +{ > > + // Is a Cpp17InputIterator or satisfies std::input_iterator. > > + template<typename _InputIterator> > > + concept __input_iterator > > + = input_iterator<_InputIterator> > > + || derived_from<__iter_category_t<_InputIterator>, > > + input_iterator_tag>; > > There's __has_input_iter_cat which we can use here. > I wonder why does inplace_vector specifically need to check > for both C++20 and legacy InputIterators? I don't think other > containers do this currently. They don't, but maybe they should (PR 100070, and the work I've been doing for std::distance and std::prev for PR 102181).Ah, and specifically for containers this is allowed by [container.reqmnts]/69: The behavior of certain container member functions and deduction guides depends on whether types qualify as input iterators or allocators. The extent to which an implementation determines that a type cannot be an input iterator is unspecified, except that as a minimum integral types shall not qualify as input iterators. We should define this generalized __input_iterator concept in a common place, say next to __has_input_iter_cat.
Yes, good idea. I think I dumped it here just so that all changes were localized in one file while I was prototyping it, and because it isn't needed elsewhere yet. But it would be more useful if it was in a common header.
