David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> writes:
To me it's like, generalizing that something with a wing, a propeller, and all things that comprise an airplane-- is an airplane. No, not necessarily. The presence of these elements do not complete the picture. It can be, say, *just a collection of parts*. Hence, pair<iterator,iterator> is just a collection of 2 iterators, nothing more.
External, non-intrusive, adaptation of a 3rd party type to make it model a particular concept that it doesn't model "inherently" is a fundamental generic programming maneuver. I don't see anything particularly wrong with making a pair of iterators model Range.
Jeremy Siek has described cases to me wherein one type can play two different roles with the *same* library. For that you need two different concept maps, to map the type into its different roles. Thus his recent "scoped concept_map" proposal.
Example please? The thing is, conceptually speaking, the pair has a very specific and well defined purpose (http://www.sgi.com/tech/stl/pair.html): ''' Pair<T1,T2> is a heterogeneous pair: it holds one object of type T1 and one of type T2. A pair is much like a Container, in that it "owns" its elements. It is not actually a model of Container, though, because it does not support the standard methods (such as iterators) for accessing the elements of a Container. ''' By "container", it's very clear that it models the tuple definition. It just so happens that STL does not have facilities for hetero-sequences. That is the domain of Fusion; and, as an STL extension, it fulfills that primary intent. It is also clear that the definition of pair does not, in any way, have anything to do with iterator ranges. I may grok what you say that there's no "wrong" here; it depends on the POV. However, if there is a conflict in definition such as in this case, it is my thinking that, for all intents and purposes, the definition that more closely follows the original intent, in the exact domain that it extends, has to take priority. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net