On Tuesday, 17 April 2018 at 15:14:02 UTC, Steven Schveighoffer
wrote:
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.
For many algorithms indeed you can’t stop w/o peeking ahead. It’s
just that lookahead of 1 is hardcoded in the range definition b/c
it’s enough for a lot of things.
But then once you are past lookahead of 1, it has to do .save +
restore if overshot. ungetc of 2 if you’d like.
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).
Might be an option. But as long as you have front/popFront/empty
as well, no concurrent stuff.
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
File caches, byLine actually does
“read up until EOL and give me slice of that”
I do not see where caching of char[] plays any significant role.
Except that due to how ranges work it likely has to do the
readline at _empty_ or on construction + popFront.
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
