David Abrahams wrote:
Thomas Witt <witt@acm.org> 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