[ConceptGCC]|
[ConceptGCC] |
ConceptGCC :Re: Refining concepts and concept_map management |
From: Douglas Gregor (dgregor_at_[hidden])
Date: 2007-06-25 16:41:24
Tom Honermann wrote:
> 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);
>
> [snip]
>
> 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.
Unfortunately, ConceptGCC doesn't handle concept maps for refinements
properly, and in fact you do not have to re-implement all of the
associated types and functions. For example, say there is already a
concept map C<X> (X is some class type) that provides all of the
behavior needed for C. When the compiler then sees:
concept_map CWithBar<X> {
void bar(X) { ... }
}
it will check that the requirement for C<X> is met. This requirement can
be met by an existing concept map (as in our case, concept map C<X>) or
by creating a new concept map C<X> that gets its definitions from the
concept map CWithBar<X>. Then, the concept map CWithBar<X> is checked
against the requirements of the concept CWithBar, and since the "bar"
function matches, the new concept map is correct.
For reference, ConceptGCC is duplicating the requirements from C in
CWithBar, so it forces you to write all of those extra functions because
it doesn't "see" the C<X> concept map when checking the CWithBar<X>
concept map. Concepts worked this way at one point, but the
specification has evolved (while the compiler has not). I'll revisit the
specification to see if I can clarify how this works. Getting ConceptGCC
to do it right... will take a bit more time and effort :)
You mentioned inheritance of concept maps... we did think about that
feature a little bit, and part of the motivation was exactly the example
you've given. However, we ended up deciding that the revised approach to
concept maps (that I described above) was a simpler, more coherent way
to write concept maps. Among other things, it makes sure that if you've
adapted from syntax in the concept map for the refined concept (C), then
you can't accidentally do something different in the refining concept's
concept map (CWithBar). That kind of mistake subverts the type system
and could cause some strange behavior, so we wanted to make it harder.
- Doug