David Abrahams wrote:
"Peter Dimov"
writes: That's the thing. It doesn't actually buy us anything.
- Simpler matching rules - Customizability for built-in types - Code is explicit about what operation it's customizing and what operation it's calling. - A few more, but you're disputing them below...
Customizability for built-in types, agreed. I don't really see the inherent value in the others. They seem like circular reasoning to me. The overload resolution rules are complex for a reason; if we could use something simpler instead, we would.
In practice people tend to respect de-facto standards; a + b is an addition, and swap(a, b) swaps a and b. The main fight is over who gets to keep the primary template.
No, the problem is what happens when you have no de-facto standard. Customizable interfaces get invented, and when they do, they are just some new thing. Everybody wants to think that they will invent the de-facto standard use for a name, but sometimes these things collide. Just look at _1, _2, et. al.
Right. And if they did not collide, nothing would become a de-facto standard, because people could keep using their own versions. There would be no pressure to resolve these collisions.
But this is not really a problem with ADL customization points, because in their purest form, there is no primary template. The primary template is usually a compatibility workaround for types that do not support the ADL interface yet.
I think you're being just a tiny bit too sanguine here. There are layers of concepts that need to be built upon commonly-used types, and there's a great danger that different libraries will pick the same simple names for different operations in their own domains. Just consider the widespread use of numeric types in all kinds of domain-specific applications. Is every library going to pick the same meaning for
zero(x)
??
Yes, I hope so. I also hope that they would pick the same meaning for x+y.