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 d

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 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.