On Fri, 6 Feb 2026, 08:33 Jakub Jelinek, <[email protected]> wrote: > 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. >
__glibcxx_concepts is the library macro that depends on both __cpp_concepts and __cplusplus>=202002L > > >
