I guess it really depends on the industry – in the gaming industry we usually reimplement the standard library inside the game engine anyway, so we have way more control of the design than the standard library there. One could imagine there are not just for_each, but also sort, any_of, swap, and more. Thus the cost of communication would have been paid since day 1.

The problem in this particular challenge was really rare in real-world scenario, because usually no algorithm needs to support function conversion or overloading to that degree. Most of the time, overloading the algorithm to explicitly support the expected function pointer or reference signature would be enough to unambiguously take the only function predicate that makes sense. Of course functors and lambdas still go into the other overload because they do not match this one.

The overloading ambiguity can be a general problem though, since every large project eventually relies on some external libraries or defines custom algorithms that use invocable predicates. The current implementations in standard library algorithms offer no protection to type errors at all, I hope they will get improved by concepts once and for all.

It seems to me the usage of another lambda / function / macro defeats the purpose of pursuing expressiveness – if you compare that to a regular cast:

“`
using B_processing_t = void (B const& b); //or whatever typedef name
std::for_each(bs.begin(), bs.end(), static_cast(f));
“`

Yes it would be uglier / one line more, but function typedef / static_cast are arguably at the same level of ugliness as macro, where no extra communication cost is required, and we do not measure c++ ugliness by syntax (but by semantic).

I understand and respect your opinion Fei. In particular, I’m with you on the fact that in general, you want the business logic to be as clear as possible and delegate the technical manipulations to the libraries. And that expressiveness is not a matter of number of lines of code.

The advantages I can see to the macro or the lambda in this case though is that they work once and for all. The macro needs to be defined once, and the technique with the lambda needs to be explained once even if it appears at several places in the codeline. As opposed to redefining some functions on the (standard or other) library, which would need more communication work to spread it to other developers in a company, and also more code to maintain, wouldn’t they?

The overhead the macro adds on the call site is the mention “resolve”, which makes sense to me in this context since the business logic is using an overload, or `[](auto&& x){f(x);}` which, granted has nothing to do with the business, but that can be explained until it becomes a common practice in a company.

Now you’re the one ultimately tipping the trade-off to one direction or the other for your workplace 🙂

My solution http://coliru.stacked-crooked.com/a/3096ce8537c4428b
or similar function-casting solution is what I would design in real-life libraries.
Adding another indirection at call-site reminds me std::back_inserter or similar clever constructs that no one really uses.

But they’re both “incomplete”, as they lack perfect forwarding, SFINAE-friendliness, and noexcept-correctness. I don’t like having to use a macro either, but it’s better than repeating the same code 3 times. This proposal was aiming to fix all these issues: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0573r0.html

I prefer the latest example in combination with Paul Dreik’s answer. There is no confusion here and you can understand what’s going on in a sec

In real-world code bases, expressiveness does not mean writing fewer lines of code in total, but making the business logic code (the largest part) clean and simple to read, so that more complex logic can be added without taking forever to understand. For that purpose, we would be willing to encapsulate all the ugliness into libraries, no matter what it takes.