@cborgolte: The idea is to convey as much information as possible about program logic and interface semantics through types.
The example using Point types does a much better job at that than the one using plain ints. As Bjarne explained in the talk, the plain ints could mean a combination of a point and extents, and there's no way to tell just by looking at the function declaration (I can give you another possibility: left side, right side, top side, bottom side). The interface using Point types makes the intent clear.
Besides, the two points don't need to be top left and bottom right; any decent implementation will accept any pair of opposite corners, in any order, as any two points with different x and y coordinates will uniquely determine a rectangle with the sides parallel to the coordinate axes (at the limit, the coordinates don't need to be different, of course, but we're usually interested in rectangles that haven't collapsed to a line segment or point). In the function implementation, the cost of testing that the two points are really top left and bottom right is about the same as for accepting any combination, so it doesn't make much sense to artificially restrict the interface. That means not using parameter names is even better for the declaration using Point types.
So, there you have it: an interface that is both more expressive and more flexible - what more could you ask for?
@Javier Estrada: No, I don't think it's a typo. He actually means 'repeatably', as in 'in a repeatable way'.
He actually explains during the talk that compilers will typically treat the 'done' variable as a loop invariant and only read it once, which means the loop will either execute forever or not at all - a predictable, repeatable, behaviour (not the more-common unpredictable mess that you may get from programs containing data races).
Using !bind(pred, _1) in the first call to stable_partition() in the definition of the gather() function template (around minute 56 of the video) won't compile, will it? (Unless the wrapper object returned from bind() overloads operator!, which I don't think it does.)
Maybe something like not1(pred) would work, assuming the definition of Predicate contains the necessary typedefs. Or a lambda, of course.
I also guess removing bind() from the first call will remove it from the second one as well, since it doesn't seem to do much there anyway (I suppose it's there for symmetry reasons).