OK, now I can answer your original question:
Question: Why have the operator| on the moved_range return another moved_range, accumulating the adaptors explicitly in a Fusion sequence? Accumulating the adaptors is necessary, because I didn't change the implementation of the existing Boost.Range's range adaptors.
Couldn't we just return the usual range adaptor types, with special metafunction logic to switch to by-value storage (rather than the default reference storage) of the adapted range when its a moved_range or an adaptation of a moved_range? The lifetime problem can be solved by your range adaptors. I chose to implement moved_range, just because adding moved_range is easier for me than changing each range adaptor implementation. Yeah, I'm lazy :-)
I understand the rationale entirely and normally this is something I would push for. In this case I believe we should be able to iterate upon your original solution and take advantage of building some optimizations into the range adaptors. I think we can then achieve a zero-cost under normal conditions implementation with opt-in explicit moving. I'm hacking up something to opt-in once and have the opt-in continue left-wise through the application of the | operator.
Regards, Michel
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I think this is merely a small iteration to your original idea, but it seems to better separate the design concerns which is motivation enough to make the bigger change. Since you are ahead of me, in terms of the amount of work you have done on this, do you foresee any issue with my slight changes? Thanks, Neil Groves