"Thomas Witt" <witt@acm.org> wrote in message news:d1vv3c$rof$1@sea.gmane.org... | David Abrahams wrote: | I can see the problem. What I am unconvinced of is that the proposed | solution is the correct solution to the overall problem. If this were | some internal boost component meant to make boost library writing easier | I would be perfectly happy, but we are talking about a library that | deals with an important concept (ranges). | | I am particularly concerned with the scalability of the solution. | How many ADL wrappers do we need to solve the problem? one for each function. | Will they become | a legacy at some point? who knows? | > | > Do try to remember that although the "artificially uglified name" will | > appear in the interfaces of all classes that model the range concept, | > there will probably be even more uses of the "real name" in user code. | | Agreed. On the other hand the usibility of these classes now takes a hit | when Boost.Range isn't present. The class author can work around this by | providing begin and range_begin functions. What might bring us back to | square one. The class user might still have trouble to understand and | memorize the right way to get at begin. I don't think I get this. | > | > Yes, the whole area of dispatching and customization of generic | > functions is nasty in C++. I've known it's problematic for a long | > time, but had a hard time expressing how bad the problem is in a way | > that would communicate to someone who doesn't do heavy generic | > programming day in and day out. | | I agree that something needs to be done. I just really want to be | convinced that the proposed changes to boost::begin are the right solution What do you suggest then. IMO the ADL problem is fairly simple and can be adequately solved by the current proposed resolution. A more "generic" mechanism when dealing with algorithms might be ok, but I don't see why it is relevant in this context. -Thorsten