On 4/15/18 6:14 AM, Dmitry Olshansky 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.
Ugh, then you get things like fungetc.
However, there are certainly cases where it's expensive to compute
front, and therefore, requires a cache. A new primitive that accesses
front and pops it at the same time would be useful. We can have selected
algorithms that can deal with it use that primitive instead (and
instrument foreach to do it). Potentially, we can create a wrapper for
all input ranges such that they support it.
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.
-Steve
