isInputRange is false for non-copyable types

[Jonathan M Davis]

On Sunday, April 15, 2018 10:14:20 Dmitry Olshansky via Digitalmars-d wrote:
> On Sunday, 15 April 2018 at 06:39:43 UTC, Jonathan M Davis wrote:
> > On Sunday, April 15, 2018 07:26:54 Shachar Shemesh via
> >
> > Digitalmars-d wrote:
> >> [...]
> >
> > It's extremely common for range-based functions to copy front.
> > Even foreach does it. e.g.
> >
> > [...]
>
> Arguably it should “move” them.
>
> This would have worked if input ranges didn’t have to cache front
> to support multiple ‘front’ calls before popFront. Which is a
> painful misfeature really as all algorithms would optimize for
> touching front once anyway.
>
> Input range should “produce” elements not keep cache of them,
> forward ranges may cache current item alright.

If that were the route that we were going to go, then front and popFront
wouldn't make any sense at all. Rather, you'd treat it more like in iterator
in Java and have next() return the next element and pop it off at the same
time. But even if we did that, it wouldn't have been appropriate in the
general case to move the element unless we put serious restrictions on what
could be an input range (e.g. that would make no sense whatsoever with
dynamic arrays or any kind of container).

In some respects it would be nice if input ranges were completely separate
beasts from forward ranges, since ideally, forward ranges would all be value
types, and input ranges would all be reference types (in which case, save
wouldn't be a thing), but that would cause it's own set of problems, because
then it wouldn't really work to have input ranges and forward ranges use the
same code, which could get really annoying. Input ranges are kind of an
abomination IMHO , because they're so painfully limited, but unfortunately,
it simply doesn't work to have all ranges be forward ranges if you don't
want to have to do stuff like buffer data. So, figuring out what we would
ideally do with input ranges and forward ranges gets to be a bit of an
interesting question.

Regardless, even if we could all agree on how ranges would ideally be
redesigned if we were doing this stuff from scratch, we're not doing it from
scratch, and for better or worse, a lot of existing code depends on the
current design. So, while I'd love to have the opportunity to sit down and
redesign the range API, I don't see how we really can - not and actually
have it implemented as part of the language or Phobos anyway.

- Jonathan M Davis