oversight with input ranges

[Steven Schveighoffer via Digitalmars-d]

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