On 6/23/20 9:47 AM, Sebastiaan Koppe wrote:
On Tuesday, 23 June 2020 at 07:30:29 UTC, Stanislav Blinov wrote:
On Tuesday, 23 June 2020 at 05:24:37 UTC, H. S. Teoh wrote:
I'm also wondering what's the motivation behind supporting
non-copyable ranges, and whether it's worth the effort and inevitable
complications to support it if it's a rare use-case.
Do you have any compelling use-case in mind, that might make this
worthwhile?
This compelling use case is staring at us from comments in this very
thread.
I am a bit on the fence about having input ranges be non-copyable.
Initially I liked the idea very much; I am a big fan of 'unique' semantics.
But just because most people don't expect hot/destructive reads, doesn't
mean we should impose such a hard restriction on input ranges. There are
use cases for popping from an input range from different places. An
obvious one would be parsing data from the network, where you pass the
input range into helper functions that parse sub-sections of the data.
You can pass a reference if you need to, there's nothing wrong with that.
They can be made to work for sure, but it doesn't make it cleaner.
On the other hand, most of the time, non-copyable is exactly what you
need...
Most of the time algorithms return rvalue ranges anyway, so move is not
necessary. I think it would actually affect calls very little, and where
it does affect them, you may find it actually fixes issues that you
aren't aware of.
-Steve
