RFC on SlidingSplitter Range

["Nordlöw" via Digitalmars-d-learn]

On Friday, 3 October 2014 at 17:46:18 UTC, monarch_dodra wrote:
>> My mistake. It's fixed now.
>
> Well, yes and no. You are still providing a moveFront that does 
> not conform to what the range interface expects. EG:
>
> auto app = appender();
> auto myRange = slidingSplitter([1, 2, 3]);
> for ( ; !myRange.empty ; myRange.popFront() )
>   app.put(myRange.moveFront());
>
> As you can see from this code snippet, moveFront is not 
> expected to pop. At all. As a matter of fact, this will error 
> out during runtime, as the loop will attempt a pop on an empty 
> range.
>
> IMO, you should just leave it out.

Ok, I removed it and added a test using std.range.moveFront 
instead.

>>> Also, what you want to check is "hasSlicing", which is more 
>>> powerful than "isRA". Speaking of which, if you don't have 
>>> "isRA", it looks like your range errors out (no "front").

Ok, I use hasSlicing instead.

> There's still the issue that if you don't have slicing, then 
> your range doesn't have "front" at all. You might as well just 
> make it a general template restriction.
>
>>> Your sliding splitter does not handle narrow strings. I'd 
>>> have thought that was the original goal. Well, it is better 
>>> to not support it at all of course, rather than doing it 
>>> wrong :)
>>
>> That's part of episode 2, for now ;)
>
> Cool.
>
> More things I saw:
> Don't make opIndex const. You have no guarantee R.opindex is 
> const.
> Also, "opSlice()" is not a range primitive. You can implement 
> it, it's basically just a no-op. The one that's important is 
> "opSlice(lhs, rhs)".
>
> Also, no point in returning an "auto ref" from 
> "slidingSplitter", you *know* it's an rvalue.

A typo. I know about the difference between auto and auto ref ;)

> If your implementation use two ranges that you slice "on the 
> fly", then you can trivially support strings, thanks to 
> popFront.

Very clever. That's what I wanted.

> I threw this together.

Superb!

It could be motivated to use

static if (isRandomAccessRange!R)
{
     // my solution for member functions...
     private R _data;
     private size_t _index;
else // assumes R is either string or wstring
{
     // your solution for member functions...
     private R _original;
     private R _right;
}

to save space in the RA-case, right?

Is isRandomAccessRange!R the correct way to check for this?

Nice unittest ;)

> I left out checks for infinity in favor of brevity:

Last thing for now:
- What do you mean by this?
- Do I have to indicate that this range is not infinite?