Jeffrey Lee Hellrung, Jr. wrote:
I think moved and move_forwarder are confusing names as I would think they would take a meaning similar to that in N1871/N1781/whatever (i.e., wrapping the adapted range's iterators in move_iterators). Forwarded is better, but my suggestion is something along the lines of "by_value" and "by_value_if_rv":
I admit that moved and forwarded are confusing names. I'm OK with any naming that is concise and clear ;)
But I think the important semantic property about this wrapper is that it effectively signals the "range adaptor operator|" to adapt *by value*, and the fact that we move to achieve this is just consequence (i.e., most of the time, we could copy, it would just be less efficient).
Yep, move is just an optimization.
Question: Why have the operator| on the moved_range return another moved_range, accumulating the adaptors explicitly in a Fusion sequence?
I don't fully understand the following
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?
So my answer might not take your point..., but let me try. * At each pipe operator, the container should be moved. * Iterators might be invalidated by move. So all the range adaptors should be applied after (or at) the last pipe operator. I did this by explicitly accumulating the range adaptors. Regards, Michel