On Wednesday, 22 April 2015 at 16:02:51 UTC, Steven Schveighoffer
wrote:
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
We could just add a flag as a second argument to isInputRange.
