Playing with conceptgcc-boostcon on Linux/x86 and looking at considerations managing concept_maps throughout code evolution...

Assume we start with code like the following and for various reasons this code cannot be modified (ie, third party or system/compiler code)

#include <concepts> concept C<typename T> { typename type; void foo(T); } struct S { typedef int type; void foo() const; void bar() const; }; concept_map C<S> { typedef S::type type; void foo(S) { s.foo(); } }

Now I come along and want to refine concept C to include a function bar():

concept CWithBar<typename T> : C<T> {
void bar(T);
}

I now need a concept_map for CWithBar<S>. The problem is that writing this concept map requires re-implementing the associated types and functions already present for the C<S> concept_map. Ideally, I'd like to be able to do something like:

concept_map CWithBar<S> : C<S> {
void bar(T) { s.bar(); }
}

or perhaps:

concept_map CWithBar<S> {
using C<S>;
void bar(T) { s.bar(); }
}

or even:

concept_map CWithBar<S> {
    using C<S>::type;    // typedef C<S>::type type; does work for associated types...
    using C<S>::foo;
    voif bar(T) { s.bar(); }
}

Looking through n2193, I haven't been able to find a way for one concept_map to inherit from another one. I know that implementing all of the concept requirements in _only_ CWithBar<S> would implicitly satisfy the concept map requirements for C<S> and allow me to have the concept map definitions for each concept requirement in exactly one place (which is my goal), however taking this approach requires modifying code that might affect the scope/risk/cost/compatibility of making the change.

Tom.