oversight with input ranges

[ketmar via Digitalmars-d]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150421/8bbd9010/attachment.sig>