https://issues.dlang.org/show_bug.cgi?id=23976

Caused by: https://github.com/dlang/phobos/pull/8738
(commit 8a9cfa2677)

Brief summary:

-----------
import std;
void main() {
	auto input = "1<2";
	foreach (pair; input.splitter("<").slide(2))
	{
		writeln(pair);
	}
}
-----------

Output before commit 8a9cfa2677:
-----------
["1", "2"]
-----------

Output after commit 8a9cfa2677:
-----------
["1", "2"]
["2"]
-----------

This is incorrect because the code asked for a window of size 2, with the default option of No.withPartial.

This broke another of my old projects that relied on the old (correct)
behaviour. :-/


T

-- 
There are three kinds of people in the world: those who can count, and those who can't.

On 6/15/2023 12:18 PM, H. S. Teoh wrote:
> https://issues.dlang.org/show_bug.cgi?id=23976
> 
> Caused by: https://github.com/dlang/phobos/pull/8738

FeepingCreature is aware of this and says he'll look into it tomorrow.

On Fri, Jun 16, 2023 at 08:41:48AM +0000, FeepingCreature via Digitalmars-d wrote:
> On Thursday, 15 June 2023 at 19:18:03 UTC, H. S. Teoh wrote:
> > https://issues.dlang.org/show_bug.cgi?id=23976
[...]
> I actually need some help with this.
> 
> The behavior of `withPartial` seems to be random! For instance, since the default of `slide` is stated to be `Yes.withPartial`, shouldn't `[["1", "2"], ["2"]]` be the correct answer, since the last element has less than two entries?
[...]

OK, sorry for the really slow response, but I finally took a look at the current Phobos code and the implementation of withPartial.  I think I've figured out how the original design works.  Looks like the original design was that the window (of size windowSize) is advanced by stepSize every iteration, stopping *once the last element of the original range has been reached*.  The withPartial parameter appears to be meaningful only for the case where stepSize > 1, because that's the only time you'll get a window of size < windowSize.

I.e., the way I understand the original, based on my reading of the code, is this: let's say we have a range like this:

	0 1 2 3 4 5 6

then for windowSize=2, stepSize=1, we have the following windows:

	0 1 2 3 4 5 6
	[ ]
	  [ ]
	    [ ]
	      [ ]
	        [ ]
		  [ ]

At this point, the window is [5, 6], which means the last element 6 of the original range has been reached, so the range stops.

But with stepSize=2:

	0 1 2 3 4 5 6
	[ ]
	    [ ]
	        [ ]
		    []

Here, after [4, 5] we haven't reached the last element 6 yet, so we have to advance the window once more.  But there are no more elements after 6, so the next window contains only [6].  This is where withPartial comes into effect: if it's Yes, which is the default (sorry, I was wrong about this in my OP), then [6], which is smaller than windowSize, will be included in the output.  Otherwise, it will be discarded.

In other words, the stopping criteria is whether the last element has been reached yet (and not necessarily at the start of a window).  When stepSize=1, this will always produce a full-sized window as the last element, because once that last full-sized window is generated, the last element of the original range has been seen, and the range will end. The only time you'll get a window of less the full size is when stepSize > 1.

Another example: if windowSize=2, stepSize=3:

	0 1 2 3 4 5 6 7 8
	[ ]
	      [ ]
	            [ ]

After the window [6,7], advancing the window by stepSize=3 passes the end of the original range, so no more windows are produced.

Hope this helps clear up the intended semantics of slide().  We should probably also document the above behaviour, because the current docs are not clear at all about exactly how this works.


T

-- 
The peace of mind---from knowing that viruses which exploit Microsoft system vulnerabilities cannot touch Linux---is priceless. -- Frustrated system administrator.

On Wed, Jun 21, 2023 at 05:34:53PM +0000, jmh530 via Digitalmars-d wrote:
> On Wednesday, 21 June 2023 at 16:49:00 UTC, H. S. Teoh wrote:
> > [snip]
> > Hope this helps clear up the intended semantics of slide().  We
> > should probably also document the above behaviour, because the
> > current docs are not clear at all about exactly how this works.
[...]
> You can go pretty far with unittest examples.
[...]

Awesome, we should include these in the PR!


T

-- 
Designer clothes: how to cover less by paying more.