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

From: Thomas Witt (witt_at_[hidden])
Date: 2005-09-06 17:55:25

David Abrahams wrote:
> Thomas Witt <witt_at_[hidden]> writes:
> 
>>Thorsten Ottosen wrote:
>>
>>
>>>My recollection is that having boost::foo() do ADL was *firmly* rejected, and
>>
>>I think I am at least partially responsible for this. And so far I am 
>>still unconvinced that making a qualified call basically a shortcut for 
>>an unqualified call is a good idea.
> 
> It's a shortcut for an unqualified call plus a using declaration.

After reviewing my earlier posts on this topic I still don't believe in 
the proposed resolution(boost_range_begin etc.) and in the specific use 
of customization points in general.

And on a related note I am unconvinced that it is fit for 
standardization (this is not meant as critique regarding Thorstens 
proposal).

AFAICS the underlying problem is retrofitting an interface to a 
component that is not owned by us. The problem usually arises in us 
being unable to invade the components namespace. As for the case at hand

std::vector<int> v;
begin(v); // error begin is member of boost not std!

does not work. In order to have our cake and eat it we move our 
interface in our own namespace where we are free to do whatever we see 
fit. The problem being that we cannot provide the interface for all 
types out there but we still want this to be extensible. Furtheremore we 
sure don't want anybody to invade our namespace, so we provide an ADL 
customization point so that other libraries can hook into our interface.

So what does that mean for the other libraries out there? They have to 
clutter their interface with these hooks that are meant only for 
communication with the boost library and that are useless if the user of 
the other library does not use boost. Apart from the fact that the hook 
strategy is unlikely to scale well (how many  potentially useless hooks 
do you want in your library?) it also seems to put the burden on the 
wrong side.

In order to make the use of a finite set of types easier we complicate 
the use and design of an infinite set of types.

There is one more point I like to make. How is the range concept going 
to look like. As far as I can see it will "degrade" to something that is 
only used in the interface between the "public" interface that is in 
boost and the component that wants to expose the boost interface.

Thomas