Re: [boost] [range] How to extend Boost.Range?

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
>>>
>>>
>>><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