protocol for using InputRanges

[H. S. Teoh]

On Thu, Mar 27, 2014 at 05:11:55PM -0700, Walter Bright wrote:
> On 3/27/2014 3:48 PM, Timon Gehr wrote:
> >Maybe empty/front/popFront should just be a single primitive, like:
> >Nullable!T get();
> 
> What if get() fails?

That's the whole point of Nullable!T: you can return null if get()
fails.

I can't say I like this, though. There are many cases in my code that
need separation of .empty from .front from .popFront, such as recursive
descent parsers or code that does if-match-then-consume algorithms. One
of the *nice* things about the current range API is that that code works
with arrays, streams, and lots of other stuff, without needing to care
about implementation details. Changing it to get() will require lots of
manual buffering and reintroduce lots of ugly boilerplate that I had to
live with in C++.

I'm with Walter on this one. Generic code should NOT assume anything
about a range it was given, and therefore it should call .empty before
calling .front or .popFront. If you "know" that a particular range
doesn't require calling .empty beforehand, then by definition your code
is no longer generic, and you just have to live with the consequences of
that. Nothing stops you, for example, from exposing a .get function or
whatever else, *in addition* to the standard range API. Then code that
knows how to deal with .get will use it, and your range remains usable
with other generic code.

Nothing about the range API dictates that .empty cannot do useful work
like initialize buffers.  That should be an implementation detail that
generic code shouldn't rely on.


T

-- 
The early bird gets the worm. Moral: ewww...