Patched 786e316de5c25a3fddeaa2003f6efb64fb5ab4a9

On 2/6/26 3:07 AM, Jonathan Wakely wrote:


On Thu, 5 Feb 2026, 23:58 Jakub Jelinek, <[email protected] <mailto:[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.



             Jakub


Reply via email to