Add Iterator#slice_after

[asterite]

Part of #7142

[asterite]

Note that this PR is complete by itself. I will add the other methods slice_before, slice_when after this one is merged. I might reuse some code between them, but I think adding one PR for each method will be easier to review.

[bew]

I don't understand why it's called slice_after based on what it does.. I seems better to me to call it slice_until, as it'll add things to the slice until the block is true.

[asterite]

@bew After it finds the value it "slices" the enumerable. Or put another way, it slices the enumerable after each time returns a truthy value.

[bew]

Ooh ok I get it, is it possible to add an explanation like this in the doc? I think it'd help memorize the naming logic (and probably help with the other iterator you're planning to add)

[bcardiff]

An spec for why the reuse is not Bool | Array(B) might be worth it ;-)

[asterite]

Yes, I thought about putting a restriction to reuse, but none of the other methods have that restriction. I'll add it just for this one and in a separate PR I'll add the rest of the restrictions.

[asterite]

Updated:

• put a restriction on reuse
• document reuse

[asterite]

Also added a small explanation to why it's called slice_after.

[bew]

if reuse is an Array, it'll still create an empty array here for nothing :(
I think you can remove this line

[asterite]

Good catch! Fixed! That's the code I originally had before adding all the reuse logic. Thank you!

[bew]

LGTM 👍

[bcardiff]

@asterite I liked the no restriction actually. I thought it was intentional to allow more flexibility: For example use an Array(Int32 | String) as a reuse in a slice_after over an Array(Int32). It is assignable from Int32 and that is enough.

[bcardiff]

For the record: removing the restriction is not possible (or not worth the effort).

[RX14]

Shouldn't @clear_on_next = true here?

[asterite]

Hmm... you are supposed to pass an empty array as a reuse value. It's not documented what happens if you pass an array that has some values already, but in this case they will be part of the first chunk. Maybe that's good. I wouldn't worry about this now.

[RX14]

The obvious usecase for passing an array as reuse is when you've just used the array from another iterator, meaning the array might not be empty. I don't think it's good to pass the burden of calling clear onto the caller, since it's easy to forget. Also, clear on an already-empty array is very cheap, so why not?

[asterite]

What if you want to get chunks but want the first chunk to have some elements beforehand? If the iterator calls clear there's no way you can do that.

I think we are just inventing use cases. Whenever I used reuse I passed a boolean. We can maybe remove the ability to pass an array altogether.

[RX14]

If you want the first chunk to have extra elements:

1. that's pretty inflexible, since you can only do it with the first chunk, not the last
2. using a named arg called reuse: is not the most clear way to achieve this.

For me, reuse is for avoiding memory allocations only. That's it's only usecase. Always calling clear makes that usecase easier with very small extra expense.