"Peter Dimov"
It is actually not _that_ unreasonable to put ADL customization point defaults in the global namespace and dispense with the "using" idiom. Moderately unreasonable, maybe. :-)
I'm interested in why you say that. After all, the likelihood of collision is infinitesimal, right? ;-)
Consider get_pointer. It was once "the protocol that mem_fn uses when faced with a smart pointer" and was not required to return a raw pointer. Now it's "the way to obtain a raw pointer from a pointer-like object" and is no longer used by mem_fn (in its TR1 incarnation). If this isn't an example of how the customization point is not owned by the library, I don't know what is. ;-)
I don't know if citing a library evolution for which you hold all the responsibility really counts. ;-)
I am not responsible for the evolution of get_pointer. tr1::mem_fn doesn't even use it.
So who's using it? [And why doesn't mem_fn use it?]
The implication of that is that customization points need to be minimized and their semantics - carefully chosen. They are even more important than the (rest of the) public interface of the library, because they can affect and shape the code of people that don't even use this particular library.
So does the rest of the public interface.
The rest of the public interface does not affect non-users.
I don't get it. Even if author A has to glom a giant ugly fribsackle onto his type so that it can satisfy library B's concept requirements, author C can use A's type with B's functions without ever having to confront the fribsackle herself.
Um, I beg your pardon? ;-)
Having a problem with the term "fribsackle?"
Library B defines requirements. Author A satisfies them by defining a function or specializing a class template. Author C uses A's public interface, which _includes_ the function or the specialization. Ergo, B's customization points
Aha! So you admit B owns these customization points! ;-)
affect C, who does not use B and may not even have heard of it.
You apparently view these implementations of B's customization points as part of A's interface. But these customizations might be supplied by a third party, adapting A to B (yes, I know there's a problem when multiple third parties get involved). I tend to see them as something A does for B's benefit, and not neccessarily for the rest of the world.
I'm not sure about the weight you're giving to these things. People supply these customization points at most once per component, and it's a "private matter between two consenting programmers." It doesn't need to affect other users of either programmers' code -- unless of course you have to worry about future name collisions ;-)
A customization point is a public protocol that needs to be followed by types in order to advertize a certain property or operation. I don't see how it can be a private matter. Library A introduces customization point f(x), library B defines f(y) for its type Y, library C uses f(x) in order to benefit from the fact that there are already types Y that support the protocol. These three libraries are totally separate.
You mean that the customization point is automatically up-for-grabs for any library to use, as soon as you advertise that it makes a type work with some particular library.
Well, I guess that's the difference between specialization and overloading. With specialization, you sorta need to have one of that library's headers around to get the declaration.
It doesn't matter, really. If the customization point is useful, it will be used. The customization points define the interface of a domain-specific class, to use your terminology.
I don't view the class as domain-specific neccessarily. Most classes will cross domains. For example, swap, from the value-type domain, applies to almost everything. I also don't view those things as really being the interface of a class. That piece of interface was defined and specified by someone else. Maybe when you say "class" you mean something like "Concept," i.e. swappable?
This interface will then be picked up by others.
Of course you _could_ define the customization point in such a way so that its usefulness to others is minimized.
Heh, yes.
Eh, of course one wouldn't use iterator_traits<>::difference_type in such a way, but I wouldn't expect you to define this kind of a customization point. You would define difference_type<X>::type, probably, to which your objections do not apply.
Right.
Anyway, my point was just that good customization points transcend a specific library, if not the whole domain.
You seem to have a point.
iterator_traits isn't an example of a good customization point.
Tell me (all) about it.
Right. But "introduced by" and "owned by" are not the same thing. Once it's introduced and adopted, the genie is out of the bottle.
What is your meaning for "owned by?"
Controlled by. Something that you can change the specification of. Something that you can change the name of. Something you can change the namespace of, if you will.
Okay.
I don't like domain tags much. Seems like a fairly high price to pay for dubious returns.
What's the cost, overall? You may "need" such an interface dispatching function anyway, to deal with builtin types.
The cost is the extra parameter and the dependency on the tag header, and with the utility function infrastructure in place, a class template instead of a tag isn't very far.
But they have many disadvantages, including not matching derived classes.
I only use such tags when I need to inject a namespace for ADL purposes via the tag.
Example, please?
I'll need to think about it. A quick scan doesn't reveal anything similar, so I might have dropped this technique. I _think_ that it had to do with the fact that one can't put overloads into std. I had an ADL interface f(x, y), where the x'es came from different namespaces, and I needed to define f( _, std::vector ). I see in the code that I have "solved" this problem by putting all x'es in the same namespace. What a hack. ;-) The other option was to add a tag and put the std:: related overloads in that tag's namespace.
Thanks.
Maybe I'll just bite the bullet and start putting overloads in std instead one day.
Live dangerously or don't live at all ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com