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
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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk