From: Eric Niebler (eric_at_[hidden])
Date: 2005-09-09 19:19:29
David Abrahams wrote:
> "Eric Niebler" <eric_at_[hidden]> 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
>>>>is also well formed and has the same meaning:
>>>> using namespace unspecified-namespace;
> 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. 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 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.
>>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
> 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
>>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?
> 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
-- Eric Niebler Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk