On Sun, 23 Mar 2014 09:00:17 -0400, Tommi <[email protected]> wrote:
On Sunday, 23 March 2014 at 00:50:34 UTC, Walter Bright wrote:
It's become clear to me that we've underspecified what an InputRange
is. The normal way to use it is:
while (!r.empty) {
auto e = r.front;
... do something with e ...
r.popFront();
}
no argument there. But there are two issues:
1. If you know the range is not empty, is it allowed to call r.front
without calling r.empty first?
If this is true, extra logic will need to be added to r.front in many
cases.
2. Can r.front be called n times in a row? I.e. is calling front()
destructive?
If true, this means that r.front will have to cache a copy in many
cases.
Is InputRange supposed to be a one-pass range and am I supposed to able
to use InputRange as a lightweight wrapper for a stream? If the answer
is yes, then I think the fundamental issue is that the
empty-front-popFront interface is not optimal for something like
InputRange. But given that's the interface we have, I think that
InputRange's front must be allowed to be destructive because the stream
it could potentially be wrapping is destructive.
A range interface only works for a buffered stream, which naturally allows
caching.
-Steve
