oversight with input ranges

[John Colvin via Digitalmars-d]

On Wednesday, 22 April 2015 at 16:02:51 UTC, Steven Schveighoffer 
wrote:
> On 4/21/15 7:31 PM, ketmar wrote:
>> On Tue, 21 Apr 2015 18:57:50 -0400, Steven Schveighoffer wrote:
>>
>>> On 4/21/15 3:53 PM, ketmar wrote:
>>>> here's the interesting oversight for isInputRange:
>>>> https://issues.dlang.org/show_bug.cgi?id=14478
>>>>
>>>> so be careful: ranges with non-copyable elements aren't 
>>>> input ranges
>>>> for now. ;-)
>>>
>>> This does seem like an incorrect limitation, and I'm not sure 
>>> if it was
>>> intentional. However, there is a lot of code out there that 
>>> expects this
>>> to work when isInputRange is true. I don't know if we should 
>>> change it,
>>> as the range definition is pretty clear in the documentation 
>>> that auto h
>>> = r.front is a required feature for ranges. What is the use 
>>> case for
>>> this?
>>
>> one possible use case was shown in bugreport. array of 
>> non-copyable
>> struct, yet i still want chain 'em, for example. or filter. 
>> or...
>>
>> struct S {
>>   int n;
>>   @disable this (this);
>> }
>>
>> void main () {
>>   S[2] arr;
>>   arr[0].n = 1;
>>   arr[1].n = 2;
>>   foreach (ref el; arr[].filter!((ref a) => a.n > 1)) {
>>     writeln(el.n);
>>   }
>> }
>>
>>
>> this code is perfectly valid, it doesn't require copying at 
>> all, yet it
>> is invalid now.
>>
>
> 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?
>
> -Steve

We could just add a flag as a second argument to isInputRange.