Hello Herb.

I see very appealing your proposal from the point of view of tools, which is a really important, if not the most important use case.

I also like to be able to chain left-to-right reading of APIs. Having C functions available for types seems to be also really appealing.

I like to do this, for example:

auto my_result = myvec.filtered([](int n) { return n % 2 == 0}).transformed([](int n) { return n * n; })).accumulate(0);

The only concern I have about this is what Bjarne Stroustrup and Gabriel Dos Reis mention in their paper: what about multi-methods? It is true that this syntax is nicer for tools.

But I think this should work both ways: member-to-nonmember and nonmember-to-member mapping. As I understand you only propose one way: from non-member to member, which is the tool use case.

But function call syntax has other appealing scenarios, being less nicer for tools, is more general for multiple dispatch, for example.

Just my two cents. Was a quick thought

EDIT: Re-reading I see the comment about multimethods that I missed before, just taking a quick look at the time.
The this not in first position is also a good idea, but I still see more natural multi-methods with function syntax. What a muddle in my head now.