David Abrahams wrote:
"Eric Niebler" <eric@boost-consulting.com> writes:
Regarding the concepts, it is correct to say, as you do, that the calls to begin(), end(), et al., must be qualified by boost::. But they also must say that the following
<quote>
is also well formed and has the same meaning:
using namespace unspecified-namespace; boost_range_begin(x);
</quote>
That doesn't look right to me. First of all, it seems to me that telling users that
using namespace unspecified-namespace; ^^^^^^^^^^^^^^^^^^^^^
is well-formed is next to useless. How is a user supposed to satisfy that requirement? Am I missing something?
It's not useless. It's saying that there exists a namespace such that after you make its symbols visible via a using declaration, an unqualified call to boost_range_begin(r) will, through the magic of ADL, be equivalent to boost::begin(r), for all types R that satisfy the Range concepts -- even if R has no associated namespaces, like int[5]. The implication of the requirement is that in order to satisfy the Range concept, users must define a boost_range_begin() overload that can be found via ADL. I put the using declaration in the requirement because without it, users might rightly wonder how a type such as int[5] could fulfill this particular requirement. The using declaration gives implementers the leeway to put boost_range_begin() someplace besides global scope, and it also gives them the leeway to call that namespace whatever they like without having to tell you. Now, if we want to allow users to make a type like unsigned short * satisfy the Range concept, we might want to change "unspecified-namespace" to "implementation-defined-namespace" so that they don't have to put their overloads at global scope. *shrug*
Secondly, and I could be wrong, but I don't think that statement can be true for some of the types modeling range.
Really? <snip>
If you want to treat a type as a range, you need to include the file that makes that type a conforming range. I don't see any problem with that.
I do. Does the type satisfy the concept or doesn't it? Normally, that question is (and should be) answerable based on the visibility of the type alone.
Why? We've already committed ourselves to letting users satisfy the Range concept non-intrusively through the use of free functions and ADL. The user can put those free functions anywhere she feels like. If they're visible, bingo! the type is a range. If not, it isn't. That leads directly to the situation Thorsten describes -- that in one translation unit, a type may satisfy the concept and in another it may not. If you have a problem with that, then you have a problem with non-intrusively satisfying a concept. Frankly, I still don't see it as a problem. <snip>
Of course. And I'm saying that for a type to conform to the range concept, it must do more than ensure that boost::begin(), boost::end(), and boost::size() are well-formed and have the proper semantics.
Aside from defining the correct traits to deduce the return types of these functions, that's all it must do. Concepts are for describing the requirements of generic algorithms.
Ah, now I understand the disconnect. From the perspective of someone writing a generic algorithm, you're right, that's all that's necessary. But what of the person trying to /satisfy/ the Range concept for their type? We're telling them that they need to overload boost_range_begin() et al., but they're looking at the Range concept and wondering how that gets them any closer. You're saying a Concept should not describe how it should be satisfied, just how it should be used. Is that right? <snip>
I think the correct approach is to document what boost::begin() et. al do. After all, for a specific concrete type the user could explicitly specialize boost::begin() et al. There's no need to provide an ADL overload.
As the Perl guys say, "There's more than one way to do it!" But I don't like Perl. :-P I like there to be one sanctioned way to do something. And I was going on the assumption that the Concept's requirements would be the final word on how to use *and* satisfy the Concept. But maybe I'm wrong. -- Eric Niebler Boost Consulting www.boost-consulting.com