isInputRange is false for non-copyable types

[H. S. Teoh]

On Tue, Apr 17, 2018 at 11:14:02AM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> On 4/15/18 6:14 AM, Dmitry Olshansky wrote:
[...]
> > Input range should “produce” elements not keep cache of them,
> > forward ranges may cache current item alright.
> 
> Well, sometimes you HAVE to cache it. For instance File.byLine is
> clearly an input range, and not a forward range. But it MUST cache
> because it's i/o that has to be buffered to be looked at! No reason to
> force caching on the user at that point.
[...]

In the past I've used range-like (i.e., iteration) APIs that do not
cache the current element. To be quite frank, they were a royal pain to
work with, because they force user code to be needlessly cluttered with
ad hoc caching schemes that pollute the code all over the place.
Instead of having the range handle the caching, all downstream code that
uses the range has to implement their own caching and/or otherwise
implement ugly ad hoc workarounds for the lack thereof.  Andrei got it
right when he designed the range API with a cached .front, and I would
be opposed to any range API design that involves a non-caching .front.

For generative ranges like std.range.generate, well, .generate exists
precisely for that reason: to be the single implementation of a caching
.front that wraps around a non-caching generating function, so that
range implementers don't have to write their own caching code, but only
need to care about writing the generating function and let .generate
handle the caching for them.  The downstream user also doesn't need to
worry about the odd semantics of a non-caching .front, but can use the
range API as usual.  Win-win.


T

-- 
Recently, our IT department hired a bug-fix engineer. He used to work for Volkswagen.