oversight with input ranges

[Steven Schveighoffer via Digitalmars-d]

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