| "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | | > "David Abrahams" <dave@boost-consulting.com> wrote in message news:ur7pkurnp.fsf@boost-consulting.com... [snip, adl_begin()] | > apart from the adl stuff, it already is like that. Did you mean to | > put in the range namespace to avoid problems with classes in boost? | | No, I mean so that the concept can be described in terms of | boost::range and Collection can become a refinement of Range. I see. | > | Then you change the Range concept to require that | > | boost::range::begin(col) works. | > | > hm...yeah...one could perhaps state both syntaxes as part of the concept, eg | > | > Valid expressions | > ============ | > begin( a ) | > or | > a.begin() | | No, you have to say boost::range::begin(col). Otherwise they could | make a.begin() valid but begin(a) invalid, and that would break | boost::range::begin. I don't like this circular dependency on the concepts: Range has a special meaning if the argument is a Collection, yet Collection is supposed to refine Range. | > perhaps the Range concept could specify | > | > Primary Template Behavior | > ================== | > return a.begin() | > | > ? | | Wha??? | | What do primary templates have to do with this? it is the behavior of the primary template that makes coillections act as Ranges. | > And maybe we don't have to talk about collection as a refinement; | > maybe a new term is in order, like "act", sa in "all Collections may | > act as Ranges". | | ... provided that "..." | | Or, we could say that certain refinements of Collection are also | refinements of Range. hm...it doesn't sound right, does it? boost\libs\range\doc\external_concepts.html described the idea of external and internal versions of concept, roughly correponding to whether functions are free-standing or members. In that terminology, we could say 1. Collection would be a refinement of InternalRange 2. ExternalRange will, by definition, work with all corresponding InternalRange br Thorsten