Eric Niebler
I wrote an article describing the "fat" std::istream_iterator and how it can be slimmed down by giving it an owning istream_range[1]. I see there already is an istream_range in Boost.Range, but it suffers from the fat-iterator problem I describe there. Is there a compelling reason why the implementation of boost::istream_range shouldn't be changed to be more like the one I describe? Also, as a commented pointed out, the same problem exists for the filtered range and the transformed range, too.
The trick, of course, will be keeping intermediate temporary ranges alive long enough to avoid lifetime issues when we chain adaptors and assign the result to a local variable. I think a range library that's sensitive to the value category of range objects and makes copies of rvalue ranges would solve this problem. Thoughts?
Is it time for Boost.Range 3.0?
[1]: http://ericniebler.com/2013/11/07/input-iterators-vs-input-ranges
Seems like we've been in this territory before... http://boost.2283326.n4.nabble.com/lifetime-of-ranges-vs-iterators-td2650349...