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?
