Once the “root” concept is explicit, in most cases it doesn’t require any more concept maps even if all of the more-refined concepts are explicit. This is because of the way we tend to use concept maps: we write one concept map for the most specific concept (e.g., RandomAccessIterator rather than Iterator, BackInsertionContainer rather than Container), and the compiler implicitly generates concept maps for the less-specific concepts.

Rodrigo: Doug came with a rationale on why it wasn’t this way. My opinion is that it was a wrong decision. Other options may exist. For example, we could have: concept, auto concept, explicit concept. http://zone-team.com.mx/temp/c2.cpp summarizes my thoughts.

You can actually get this kind of behavior from the current concepts proposal, by using associated requirements rather than refinement. Check out how the OutputIterator concept is specified, which boils down to this:

concept Iterator<typename Iter> {
  // basic iterator requirements
}
 
auto concept OutputIterator<typename Iter, typename Value> {
  requires Iterator<Iter>;
  // assignability requirements to allow, e.g., *i = value
}

Here, Iterator is an explicit concept, so you need to write a concept map for it (or one of its more-refined concepts, like RandomAccessIterator) to “opt in” to the iterator system. Then, however, you get the OutputIterator concept automatically matched for your iterator types for any Value type that can be assigned to the reference type of the iterator. I think this gives basically the same capability as the non-auto, non-explicit concepts in your example, and it has definitely come in handy in the Standard Library.

Thanks for coming out to share ideas and comments; it’s great to see different perspectives on a feature like Concepts.

I am sure the decision we reached in Frankfurt was the right one for both C++ and Concepts. And certainly this Sohbet | muhabbet was not a decision to kill Concepts but to give it more time so that we could produce a well honed feature to include in the release of C++ after C++0x.

I consider ID more convenient than TD. In fact, my full opposition to the “nothing-is-explicit” or the “explicit-refinement-only” alternatives is because they are subsets of the ID in terms of power.

However, I really hate the number of explicit concepts the ID tends to generate. I find the fact that BackInsertionContainer and friends are explicit embarassing considering they are refinements of another explicit concept: Container. If a type is explicitly told to be a Container, they should be able to automatically match the mentioned refinements. If the types are’t Containers, they shouldn’t.

Doug came with a rationale on why it wasn’t this way. My opinion is that it was a wrong decision. Other options may exist. For example, we could have: concept, auto concept, explicit concept. http://zone-team.com.mx/temp/c2.cpp summarizes my thoughts.

The optimal solution is between “too much explicit” and “explicit enough”. And no, TD isn’t “explicit enough”. ID is closer to that lower bound than TD is.

Hi Rodrigo,

The question is, in between what and what? It’s very easy to say that the right answer probably lies between two competing points of view, but the proposal that was voted into the WP already has optional implicit matching (auto concepts).

I see. I think the optimal solution may be somewhere between, but it seems it starts getting more complicated (at least without a whole redesign). Thanks for your reply.

And thanks to Dave for fixing my code!

Rodrigo, I think I went in and fixed the code up; does that look better? I’ll try to track down this bug. Sorry for the inconvenience.

f(some_container( ));    // okay, meets the requirements of BackInsertionContainer
f(not_a_container( ));   // okay, meets the requirements of BackInsertionContainer

The “Indiana” group discussed similar examples back in 2005, and we decided that “auto” should really mean “auto”: if you match the syntax of an auto concept, it works even if there is an explicit concept as a root. ConceptGCC actually had this wrong (it’s fixed now), but the specification is clear.

The net effect of this behavior is that you can actually turn any explicit concept “C” into an auto concept with a little trick:

concept C<typename T> { 
  /* ... */
}
 
auto concept AutoC<typename T> : C<T> { }
 
template<AutoC T> concept_map C<T> { }

In my opinion explicit refinement -can’t- replace explicit concepts.

As I understand it, explicit refinement forbids inheritance-like implicit matching. This works for things like iterator (iterator is auto, but walking down the refinement tree can be limited in certain points). On the other hand, explicit concepts can prevent implicit matching of the root too.

I think of this mechanism:

 
concept Container;    // explicit, this is the root of the concept tree
auto concept FrontInsertionContainer : Container;
auto concept BackInsertionContainer : Container;
// etc. unfortunately all of these are explicit in the latest draft
 
struct some_container { /* deque interface here */ };
struct not_a_container { /* deque interface here */ };
 
concept_map Container { };    // we explicitly match the root
 
template
void f(C);
 
f(some_container( ));    // ok, the root is reacheable and it meets BackInsertionContainer
f(not_a_container( ));   // bad, it may match BackInsertionContainer, but the root isn't reacheable

Explicit concepts (or explicit refinement) could be used to make some inner nodes unreacheable unless stated otherwise. All auto-nodes can be reached if the parents can be reached.

I don’t think the counter-arguments are that strong. There is no dispute that, if a type accidentally matches a given auto concept, it can cause serious problems, such as the InputIterator/ForwardIterator overloading problem described in Explicit Model Definitions are Necessary, where the library ends up performing an incorrect optimization due to an accidental match. The argument against using explicit concepts is that the benefits of less typing (i.e., the elimination of “empty concept maps”) for the user outweigh the dangers of accidental matching. In part, the discussion is so heated because we’re dealing with two properties that are hard to quantify:

1. How often will users have to write an “empty” concept maps, and will they be viewed as purely syntactic noise?

2. How often will accidental matches occur, and will these matches result in bugs that require a significant amount of time to find and fix?

Whether you think that a particular concept is explicit or not depends on how you answer those two questions, your tolerance for risk, and so on. From what I’ve seen, people tend to overestimate the number of empty concept maps one needs to write (#1) because they forget the role of concept map templates in the development process. For example, a Graph library like the Boost Graph Library is likely to have graph concepts (e.g., IncidenceGraph) and graph data structures (like adjacency_list) that match those concepts. The author of that library is going to write a concept map template in the library that says that every adjacency_list is an IncidenceGraph, because that concept map template will make sure that the concepts and data structures keep in sync (since concept map templates are fully type-checked), documents for the user that every adjacency_list is an IncidenceGraph (which would otherwise be just a comment somewhere), and eliminates the need for the user to write concept maps in the common case.

The conceptualization of the standard library probably doesn’t need any explicit concepts (explicit refinement as Stroustrup calls it could solve those special cases). But getting rid of explicit concepts completely, as I see it, was an extreme alternative.

Well, we clearly have to do -something- about the InputIterator/ForwardIterator problem I mentioned previously (as well as the RandomAccessIterator/ContiguousIterator problem Stroustrup uses to describe explicit refinement). I’ve seen this same problem show up in most of the other C++ generic libraries I’ve worked on, so it doesn’t seem to be an isolated example. Explicit concepts are one obvious way to solve this problem.

I don’t know whether explicit refinement solves the problem as well as explicit concepts or not. The discussion of explicit refinement on the committee mailing list ran for more than 200 messages, and participants weren’t clear about how explicit refinement really worked. Under some interpretations, it had certain type-safety problems where a type could be a ContiguousIterator in one call but only a RandomAccessIterator in another call. Under other interpretations, explicit refinement was just an alternative syntax with the same semantics as explicit concepts. Without a more detailed specification, we can’t really meaningfully evaluate explicit refinement: there are just too many open questions.