What I find interesting is the reasoning behind that quote. Some of it has to do with duck typing (e.g. strings are Addable?!), though he also brings up the tradeoff between freedom in an algorithm's implementation vs freedom in the types it accepts (a tradeoff which is very real in rust).
Other interesting things I notice:
It comes with a clean shorthand syntax out of the box; it appears these are statically dispatched:
void sort(Sortable xs);
void sort(Sortable& xs);
Also, it permits specialization in an interesting manner: (see Section 6)
void advance(Forward_iterator p, int n) { while(n--) ++p; }
void advance(Random_access_iterator p, int n) { p += n; }
void use(vector<string>& vs, list<string>& ls)
{
auto pvs = find(vs,"foo");
advance(pvs,2); // use fast advance
auto pls = find(ls,"foo");
advance(pls,2); // use slow advance
}
How does the compiler figure out how to invoke the right advance? We didn’t tell it directly.
There is no defined hierarchy of iterators and we did not define any traits to use for tag dispatch.
...
There are a few technicalities related to the exact comparison of concepts for strictness, but we
don’t need to go into those to use concept overloading. What is important is that we don’t have
to explicitly specify an “inheritance hierarchy” among concepts, define traits classes, or add tag
dispatch helper functions. The compiler computes the real hierarchies for us. This is far simpler
and more flexible.
Not only does this design choice align well with the difference in philosophies between C++ and Rust; but I'm a bit surprised that it is even possible!