Actually the up side to value semantics is that it can take full advantage of move operations, so that if operating on an l-value your code only need copy the data the first time, then move kicks in for the rest of the chain... (i.e., mydata | filter(f) | reverse() | take(10) - only the filter() call will create the copy). And if you are operating on an rvalue no copies will be made at all.
Have a look at this: https://www.youtube.com/watch?v=YJIaGRDIyEE
Eric Neibler's approach (which I am really looking forward to!) is to state that range operations should never take ownership of the original data and therefore operations should be performed lazily. This prevents the rvalue optimisation, but enables lazy evaluation.
Its just a trade-off, but the value semantics approach isnt as bad as you might think...
edit: on further inspection the last paragraph of the article mentions this but doesnt go into detail.
Since it is a template you could always use universal references to avoid copying where not needed:
template <typename Collection,typename unop>
void for_each(Collection&& col, unop op){
std::for_each(col.begin(),col.end(),op);
}
I'm happy to see more people reading Bartosz, I find his blog very interesting. One point to emphasise about that particular post is that the proposed range library he discusses is already available today, and has been for some time, in the much overlooked boost.Range library.
For a more complete perspective on this sort of thing, I recommend Eric Neibler's blog and Bartosz Milewski's blog. Here's somewhere to start. You'll find Neibler's blog linked from there:
http://bartoszmilewski.com/2014/10/17/c-ranges-are-pure-mona...