Nonsense. See the bit about this in the middle of my post. A programmer isn't more likely to use any alternative correctly. Implementing a large number of decorations, even templates, only changes how they will use it incorrectly. It is always possible to use a method as an interface--to the limits of your compiler; so, where do you draw the line?
Which is exactly what I was hinting at that member functions (or free functions) are less error-prone than algorithms and you should be preferred when possible.
Even the function provided by anon is not an alternative for 'std::sort'. It allows for only a very small sample of the functionality.
So, you would call this method based on the anon decoration 'lexicographic_sort'.
Most likely, I would try to encapsulate std::sort via different member functions in objects, yes.
What do you name this function:
What about this one:
sort(r.begin(), r.end(), _1(&type::accessor1) < _2(&type::accessor1));
It goes on and on... And according to you inheritance should be preferred so that this too is a method:
sort(r.begin(), r.end(), _1(&type::accessor2) > _2(&type::accessor3));
sort(r.begin(), r.end(), _1(&type::accessor3) < _2(&type::accessor3));
Because it gives the illusion or whatever you want to call it that the object is sorting itself.
Well, that was interesting.