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.
signature.asc
Description: PGP signature
