Yes, My entire comment is about trivial post-hoc mapping. sorry for not being clear earlier.

you said : “A ForwardIterator could masquerade as a BidirectionalIterator in exactly the same way as InputIterators often masquerade as ForwardIterators. In practice, it’s less likely to be an issue with BidirectionalIterator, since it is syntactically more distinguished from ForwardIterator than ForwardIterator is from InputIterator. But it’s just a question of degree.”

My reply is : I may defer this to my reply to Mr.Gregor reply, but can you give me your version about the expanded version of this statement, especially I do not understand about ForwardIterator masquerading as BidirectionalIterator, since both concept can be differentiated syntactically (isn’t it ?).

you said : “I have two questions:

1. Were you planning to document somewhere that it’s a BidirectionalIterator?

2. Were you planning to embed an iterator_category typedef? “

   1. Is it enough to have an iterator the required operator/operations (operator ++ , — , *, etc.) to be recognized as BidirectionalIterator? I am aware that it is possible to define types that conform syntactically to BidirectionalIterator Syntactically but does not conform to it semantically. But I am consenting adult, and I am quite willing to take responsibility of my action.

   2. Why do we still need iterator_category typedef if we already have concept ?

you said ” “Can you explain in what way it clarifies those roles? Is that experience of clarification due to the changes N2906 would make to those roles, or simply to the paper’s explanatory text? If the former, how did the specification sans-N2906 changes make those roles unclear?”

My answer: I personally has a little theory, something like this: If there is a type T and a concept C, there are two things that need to be done with T and C

1. Check if T is a model of C. Let’s call this “Discrimination Role”
2. If T is too different with C’s archetype, force T to become model of C by adding more information . Let’s call this “Adaptation Role”

With N2906, the Discrimination Role is primarily the job of type checker and concept declaration. concept_map primary role is adaptation role. This is possible because N2906 makes the default in favor to what we call auto concept. Let’s talk about default later. By not making the default favoring auto concept, we give concept_map much more responsibility to Discrimination role, thus making the role somewhat overlap with type checker.

“Are you saying that concept maps should never be used in other situations, or that you should never be forced to write concept maps in other situations, or something else?”

Why should I state the obvious that a type with operator (++ , –, * ) and has appropriate semantic (which I guarantee myself) is bidirectional iterator. I mean, It’s more work and it’s verbose, right? and more importantly template without concept in principle does not require anything like that.

“I assume you’re just ignoring post-hoc adaptive mapping now, because if you ever want to do that, you need a concept map, auto concept or not.”

I think concept_map in post-hoc adaptive mapping is essential, My question is why we need it in trivial post-hoc mapping (well, not really. I actually ask why something as trivial as BidirectionalIterator is not auto concept, but it come close in spirit).

As additional note, I think N2906 is proposing elimination non-auto concept in the name only, since, as you said, it still possible for us to define something like non-auto concept. However it is achieved by making the refinement explicit, and taking analogy from inheritance, it will require more thought to do that. So, I guess (may be wrong, I do not write N2906) it is all about shifting the default in favor to auto concept.

template<BackInsertionSequence Cont> concept_map Stack<Cont> {/*...*/}

It seams there are two ways of saying that every instance of concept A is also an instance of concept B: one is the concept map as you describe; the other is concept refinement. Would concept-based function overloading work for the concept_map way too? I.e. if I have two function overloads: one for BackInsertionSequence and one for Stack and I call it for vector:

std::vector<int> vec;
function(vec);

Will the compiler prefer either overload, or will I have an ambiguity?

I am not sure I understand. Do you mean that omitting the typedef will work, like that:

template<BackInsertionSequence Cont>
concept_map Stack<Cont>
{
  void push(Cont &c, const value_type &x)
  { c.push_back(x); }
  ...
}

I thought that only by writing the concept map, I already state that if Cont which is any BackInsertionSequence has member typedef value_type (which it always does), and Stack‘s concept requires the member typedef of the same name. The two should be matched automatically.

That definition is there for exposition purposes, to call out the relationship between the value_type of ‘Cont’ when viewed as a BackInsertionContainer vs. when ‘Cont’ is viewed as a Stack. The definition is technically redundant, since Cont::value_type is just a shorthand for BackInsertionContaienr<Cont>::value_type.

Yes, such concept maps can coexist in a single program. During the development of the concepts proposal, I wrote the following paper to argue in favor of this, using the term “scoped concept maps”.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2098.pdf

Subsequently, this idea was accepted and incorporated into the draft standard.

The way for such concept maps to coexist is for them to be defined in separate namespaces. To control which concept map is used, you can choose to import one or the other of the concept maps from its namespace (there’s a new kind of using directive for concept maps).

The standardese for scoped concept maps is available in the following paper:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2414.pdf

typedef Cont::value_type value_type;

Regards.

It potentially has the same problem, since one could easily have a ForwardIterator with an operator-- that doesn’t have the meaning required for it to be a BidirectionalIterator. However, we (as a community) have a lot of experience with the iterators, and such an type is rather unlikely. The BidirectionalIterator concept is so widely used that it’s possible it could be auto and it probably would never matter. However…

The decision to make a concept “auto” or not is something that’s generally done when we initially write the concept, before we’ve had the years of experience we have with iterators. Given that the ForwardIterator and InputIterator concepts look syntactically different, I’m willing to bet that many people would have made ForwardIterator “auto”. Then, after a bunch of code was written without concept maps, we’d hit the first istream_iterator instance and we would have a serious problem: ForwardIterator would have to become non-auto and now we have to write a bunch of concept maps to fix existing code. Concepts evolve over time, as we find more models of those concepts (“hey, we can provide iteration through a stream with this interface!”) that change our understanding of existing concepts and introduce new concepts (e.g., putting MultiPassInputIterator between InputIterator and ForwardIterator in the concept hierarchy). Non-auto concepts allow such seamless evolution, because the user has stated their intentions; auto concepts make evolution harder, because we have to guess at the intentions of users.

So, unless you’re dealing with some really simple syntactic concept, I would not make a concept auto.

By not making it auto concept, we have to write concept_map with empty body since I already make my iterator class conform structurally (thus there is nothing to map).

When you write your iterator class, you already make an explicit statement that your iterator conforms to the BidirectionalIterator concept. It looks like this:

typedef std::bidirectional_iterator_tag iterator_category;

A concept map is the same kind of statement, but a concept map actually has teeth: the compiler will check that assumption, to make sure you got all of the various operators and their variants declared correctly. Once you’ve been able to compile the concept map, you know that you’ve met the syntactic requirements of the concept, and there will be no surprises, either now (“why didn’t it pick the BidirectionalIterator overload over the InputIterator one? I could swear that I implemented all of the requirements of BidirectionalIterator…”) or later (“someone must have tweaked the interface to my iterator type, because now it’s failing to get used as a BidirectionalIterator”).

I personally like N2906, since it clarifies the role of concept and concept map.

N2906 presents a different view of concept maps. It views concept maps more as a fix (when syntax doesn’t line up) or as a necessary evil (when we’re forced to use explicit refinement). I have a very different view: I view concept maps as a part of the generic programming process, documenting and enforcing the relationships between the types I write and the concepts they are meant to model.

I personally dislike having to write concept map if I know that certain type already conform both structurally and semantically to a concept. I think writing concept map should be reserved to a situation where there are concepts that has same syntactical requirement but different semantic requirement, and I think those kind of concepts are rare. By making concept not auto by default, I believe we choose the wrong default.   

How do you “know” that a certain type already conforms both structurally and semantically? Aside from the most trivial of concepts, it’s a significant amount of work to make sure that your type meets every single requirement of a particular concept. Testing that type with an algorithm or two doesn’t really help, because not all algorithms use all of the requirements of the concept.

I work on a C++ compiler (written in C++), and I was shocked at how many broken iterator types we had that were in continuous use: we’re missing iterator_category’s and “pointer” types and “difference_type”s and so on, sometimes we have bad return types for operator++/operator--, etc. These iterator types “work” with some templates, fail with others, etc., because they are wrong even though the author “knew” that the type conforms to the appropriate iterator concept.

By writing a concept map, I know that I have met the syntactic requirements of a concept because the compiler has checked that for me. Anything less than that is a guess, and a hedge that things won’t get changed in the future.

I defer to Doug on the actual reasons, since he wrote the wording, but I can give you my opinion: because it doesn’t need to be, and it wouldn’t buy you much.

specifically, BidirectionalIterator does not have problem like ForwardIterator and InputIterator.

In principle, it does. A ForwardIterator could masquerade as a BidirectionalIterator in exactly the same way as InputIterators often masquerade as ForwardIterators. In practice, it’s less likely to be an issue with BidirectionalIterator, since it is syntactically more distinguished from ForwardIterator than ForwardIterator is from InputIterator. But it’s just a question of degree.

By not making it auto concept, we have to write concept_map with empty body since I already make my iterator class conform structurally (thus there is nothing to map).

I have two questions:

1. Were you planning to document somewhere that it’s a BidirectionalIterator?
2. Were you planning to embed an iterator_category typedef?

I personally like N2906, since it clarifies the role of concept and concept map.

Can you explain in what way it clarifies those roles? Is that experience of clarification due to the changes N2906 would make to those roles, or simply to the paper’s explanatory text? If the former, how did the specification sans-N2906 changes make those roles unclear?

I personally dislike having to write concept map if I know that certain type already conform both structurally and semantically to a concept.

Okay, here’s where this article is relevant. Are you talking about trivial post-hoc mapping now?

I think writing concept map should be reserved to a situation where there are concepts that has same syntactical requirement but different semantic requirement,

Are you saying that concept maps should never be used in other situations, or that you should never be forced to write concept maps in other situations, or something else?

I assume you’re just ignoring post-hoc adaptive mapping now, because if you ever want to do that, you need a concept map, auto concept or not.

and I think those kind of concepts are rare. By making concept not auto by default, I believe we choose the wrong default.

That is the argument made by N2906.¹ It’s an easy argument to understand. The basis of countervailing arguments is much more subtle, and requires careful analysis of the different ways in which concepts and concept maps are used. That’s why we’re running this article series. Once you look at the issue with awareness of these distinctions, I think the imperative to make concepts auto by default is far less compelling, but we need one more article to finish laying that groundwork. Of course, by the end, you may still think concepts should be auto by default, and that’s fine. In the meantime, I encourage you to try thinking about the issue in terms of the concept and concept map classifications we’ve laid out, and see if it changes anything for you.