Thorsten Ottosen wrote:
Could we agree on a naming scheme/implementation scheme for the customization-points?
I prefer
range_begin() range_end() range_size()
to
boost_range_begin() boost_range_end() boost_range_size()
and think these identifiers are unique enough, the small amout of global costomization-points taken into consideration.
I'd like to comment on a more general point than just the names: If we offer customizations points for a specific library, why should we use ADL at all? Compared to a customization point bound to the library's namespace (e.g. boost::customize::range::begin, etc.), ADL leads to less typing to write down the specializations (which is nice) and reserved names in other namespaces (which is bad). And AFAICS, there is no difference for the users of the customized UDTs. The intrusiveness of reserving names in other namespaces is what worries me, so I'd tend to avoid ADL for the range library's customization points. It might also lead to a cleaner design on the user's side as the user will more likely separate his UDT from the binding to the range library (although that's just a wild guess). To me it seems that ADL only makes sense if we can hope for UDTs to provide certain functions (with the right semantics) without the UDT's author knowing about us. Take swap() as an example. It's a reasonable (although potentially wrong) assumption that using std::swap; swap( x, y ); might find a more efficient implementation for swap than calling std::swap directly. But we can not (and should not) assume that the author of swap() has any idea who uses his function. Don't forget ADL's roots: Operators. Operators have (or really: should have ;) a clear semantics. And swap() is close to being an operator semantically, that's why ADL is a good idea for swap, too. Man, I even wish swap would be a real operator, as well as a I'd wish for a move operator. This is where ADL makes sense and should be applied. All other cases of ADL I've seen so far were more or less dangerous. YMMV. Regards, Daniel