On Fri, Feb 06, 2026 at 08:07:08AM +0000, Jonathan Wakely wrote:
> On Thu, 5 Feb 2026, 23:58 Jakub Jelinek, <[email protected]> wrote:
>
> > On Wed, Feb 04, 2026 at 05:42:52PM -0500, Nathan Myers wrote:
> > > +#ifdef __cpp_concepts
> > > +template <typename _Kt, typename _Container>
> > > + concept __not_container_iterator =
> > > + (!is_convertible_v<_Kt&&, typename _Container::iterator> &&
> > > + !is_convertible_v<_Kt&&, typename _Container::const_iterator>);
> > > +
> > > +template <typename _Kt, typename _Container>
> > > + concept __heterogeneous_key =
> > > + (!is_same_v<typename _Container::key_type, remove_cvref_t<_Kt>>) &&
> >
> > Shouldn't this be __remove_cvref_t ?
> > I see
> > +FAIL: g++.dg/concepts/expression.C -std=gnu++17 (test for excess errors)
> > +UNRESOLVED: g++.dg/concepts/expression.C -std=gnu++17 compilation failed
> > to produce executable
> > remove_cvref_t is C++20 feature, and while concepts are also a C++20
> > feature, we allow -fconcepts -std=c++17 to enable concepts already.
> >
>
> Then maybe the new concepts should be guarded by __glibcxx_concepts for the
> library support, or by a macro specific to the container features.
>
> We don't need or want to find that concept for C++17.
It is guarded exactly by __glibcxx_concepts and that is saidly defined
for C++17 as well, given
if (flag_concepts && cxx_dialect > cxx14)
cpp_define (pfile, "__cpp_concepts=202002L");
where flag_concepts is always set for cxx_dialect >= cxx20, but can be
specified in other modes as well.
So -fconcepts -std=c++17 is some kind of language dialect which includes
C++17 and small parts of C++20.
Jakub
