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
