On 4/22/15 12:10 PM, John Colvin wrote:
On Wednesday, 22 April 2015 at 16:02:51 UTC, Steven Schveighoffer wrote:
Yes, I agree this is a valid use case. I don't think we can change
isInputRange, because other code may depend on that requirement of
copyability, but it is probably possible to alter algorithms so they
can accept these "not-quite" input ranges. Definitely proxy or
decorator type adapters that provide a proxy for front shouldn't be
restricted to using only copyable range elements.
1st step is we need a trait to define what we are looking for, then
the next step is to simply alter all the appropriate algorithms to use
it. It shouldn't hinder any code that exists if we do that.
So what should be the name of this beast?
We could just add a flag as a second argument to isInputRange.
Yeah, I like this. But now we have to name the flag :)
I don't think it should be a bool, because:
isInputRange!(R, true)
Is pretty obtuse. I'd rather see something like:
isInputRange!(R, RangeOption.NonCopyable)
Or whatever name we come up with.
The nice thing about this solution is that the range options could be
passed down the trait chain, so isForwardRange easily gets this ability
as well.
-Steve
