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