[RFC] I/O and Buffer Range

[Dmitry Olshansky]

31-Dec-2013 05:53, Joseph Cassman пишет:
> On Sunday, 29 December 2013 at 22:02:57 UTC, Dmitry Olshansky wrote:
>> [...]
>
> Interesting idea. Seems to fill a need I have been facing with some
> parsing code.
>
> Since I was unclear about how its functionality compares to ForwardRange
> I took a look through std.algorithm. If typed versions of
> lookahead/lookbehind were added it seems like ForwardRange could be
> replaced with this new range type, at least in certain places. For
> example, it seems to me that the following code (from the article "On
> Iteration"
> https://www.informit.com/articles/article.aspx?p=1407357&seqNum=7)
>
>     ForwardRange findAdjacent(ForwardRange r){
>        if (!r.empty()) {
>           auto s = r.save();
>           s.popFront();
>           for (; !s.empty();
>                 r.popFront(), s.popFront()) {
>              if (r.front() == s.front()) break;
>           }
>        }
>        return r;
>     }
>
The trick is that the name Forward range is misleading actually (I was 
surprized myself). A proper name would be ForkableRange, indeed look at 
this code:
        auto s = r.save();
        s.popFront();

s is a fork of r (independent view that has a live of its own).
The original algortihm even _reads_ easier if the correct term is used:

        auto s = r.fork();
        s.popFront();
        ...
Now it's clear that we fork a range and advance the forked copy one step 
ahead of the original.

> also could be written as
>
>     BufferedRange findAdjacent(BufferedRange r) {
>        for(;!r.empty;r.popFront()) {
>           if(r.front == r.lookahead(1)[0]) break;
>        }
>        return r;
>     }
>
Aye, just don't forget to test lookahead for empty instead of r.empty.

> Perhaps the mark and/or slice functionality could be leveraged to do
> something similar but be more performant.
>
> If anyone can see how the new range type compares to ForwardRange that
> would be cool.

I'm thinking there might be a way to bridge the new range type with 
ForwardRange but not directly as defined at the moment.

A possibility I consider is to separate a Buffer object (not a range), 
and let it be shared among views - light-weight buffer-ranges. Then if 
we imagine that these light-weight buffer-ranges are working as marks 
(i.e. they pin down the buffer) in the current proposal then they could 
be forward ranges.

I need to think on this, as the ability to integrate well with 
forwardish algorithms would be a great improvement.

-- 
Dmitry Olshansky