oversight with input ranges

[Jonathan M Davis via Digitalmars-d]

On Tuesday, April 21, 2015 23:33:38 ketmar via Digitalmars-d wrote:
> On Tue, 21 Apr 2015 15:48:25 -0700, Jonathan M Davis via Digitalmars-d
> wrote:
>
> > On Tuesday, April 21, 2015 19:53:47 ketmar via Digitalmars-d 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. ;-)
> >
> > If
> >
> > auto h = r.front;
> >
> > doesn't work, then I don't think that it can be a range. And if that
> > means that elements have to be copyable to be in a range, then I think
> > that they're going to have to be copyable. There is going to be _way_
> > too much code out there that does
> >
> > auto h = r.front;
> >
> > for it to work to try and claim that something is an input range when
> > that line doesn't work. And IIRC, C++ STL containers require that their
> > elements be copyable in order to work, so it's not like we'd be the
> > first to require this sort of thing.
>
> the thing is that chain, or filter, or other algorithms are perfectly
> able to work with such ranges, yet it is forbidden now. it looks like
> arbitrary limitation to me.

Just because a few algorithms happen to work with non-copyable elements
doesn't meant that it works in general. I can understand why you'd want to
be able to do it, but not being able to do

auto h = r.front;

is such a huge limitation that I don't think that it's even vaguely
acceptable. I can guarantee that there is a lot of code out there that does
it. Just grepping Phobos quickly finds a few cases, let alone digging into
all of the code that exists in the wild. If anything, the problem that we've
run into is folks who keep front around after popFront has been called
(which doesn't always work with input ranges - e.g. byLine), and to do that,
you have to be able to copy front, so clearly, folks have been doing that.

The definition of input ranges has quite clearly included

auto h = r.front;

from the very beginning. This isn't new. And given that the C++ STL gets
away with its containers not working with non-copyable elements, I think
that that proves that you can have a major component in the standard library
- containers no less - not support copyable elements and have it work and be
acceptable. Also, AFAIK, this is the first time anyone has ever brought up
this complaint for D ranges. So, while I'm sure that it's a limitation that
might be irritating in some cases, I also think that it's pretty clear that
it affects a very small percentage of the users out there.

If we were starting over, then maybe we could have something like
hasCopyableElements and indicate that range elements aren't guaranteed to be
copyable without that, but that would break too much code at this point, and
honestly, we have too many traits like that already. Writing fully correct
range code that takes into all of the stray cases is ridiculously hard -
especially if you try and wrap a range without losing any of its
capabilities while wrapped. We really need the common case to be easy, and
disallowing copying range elements without testing for that capability first
is not user-friendly at all. Even if it were considered more correct from a
technical standpoint, folks just wouldn't do it.

And since isInputRange has guaranteed that elements have been copyable,
I think that it's perfectly reasonable that it's been assumed that they
would be, and changing that at this point just isn't worth it.

- Jonathan M Davis