Using this form, without the wrapping function, also means you can make a named lambda at local scope within a function.

Indeed! Typo fixed, thanks.

bool operator()(int x) { return a_ <= x && b_ <= x; }
vs
[a,b](int x) { return a <= x && x <= b; });)

Thanks for the appreciation. If you like the theme, don’t hesitate to let me know what particular topic you’d like to read about!

Thanks for the hint with the book. I read it a while ago but apparently forgot much of it already. 😉 However, things are a bit clearer now. Thank you for the great work, I always enjoy reading your posts.

Fair enough, I get your point.
And about your last question, you may be interested in reading Item 34 of Scott Meyers’ Effective Modern C++, where he provides a very detailed answer.

I agree, readability on the call site is significantly improved. However, I was thinking that the logic within the resist function might be needed some place else and than it would be strange to call a function returning a function with the logic. Thus, I assume the implementation of the logic within the lambda in resists() already exists, e.g. as a free function.

If that is the case, there are (at least) 4 options for copy_if:
1) use std::bind
2) use a lambda within copy_if that forwards to the free function
3) use a function returning the result of std::bind
4) use a function returning a lambda that forwards to the free function

While 1) and 2) are a bit cluttered on the call site, 3) and 4) feel a bit overengineered. The level of abstraction would already be ok with 1) and 2) and another indirection makes the code harder to navigate. I think, I’d still go with option 1. I was just wondering, why std::bind seems to be replaced by lambdas all over the place.

The benefit I would see is that the calling code doesn’t show “bind” nor its accompanying placeholders, which, in my opinion, are extra info hindering the readability of the call site.

Yep. The only case I can see where things could go wrong is if the const& passed to the function is the result of an implicit conversion. In this case, the converted object is destroyed when the function returns, and the lambda would still hold a reference to it. But this is not the case here, and implicit conversion are advised against in general (but there is one from string literals to std::string!)