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.
