Add split_inclusive #917
Add split_inclusive #917
Conversation
|
Apologies; I didn't realize I had to run a different command to run the doc tests. I'm fixing those now. |
|
|
That's what I'd have thought. It's possible there are just so many tests that I didn't see the failures as they scrolled past. I was expecting to see them reported at the end and might just not have been vigilant enough. Anyway, I looked a lot more closely this last time. :p |
|
I've attempted to correct the behavior of the iterator to match the behavior expressed by split_inclusive in std. I've also attempted to make the docs less awful. |
This changeset adjusts the documentation to more closely match that found in std for split_inclusive. It also changes the behavior such that the matched substring appears at the end of each element as a terminator rather than at the head of each element. Sorry; I never actually *read* the split_inclusive docs in std.
|
Why was this closed? |
|
Well, there was no response for a week, and I don't like leaving things in limbo. |
|
Fair enough. It would help communicating your expectations up front next time, and I would be able to tell you right away that I won't be able to live up to them. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@shner-elmo We should keep discussion about this on the actual issue #681 (comment). Not on closed PRs. |
This adds a new iterator type and a new method to both the byte and unicode version of
Regex. Most of the code is copied from the ordinary split iterator. My doc example is probably terrible, but who doesn't like fruit?Before opening this PR, I checked to see whether it's possible to mimic this behavior using, say, a non-capturing group with the regular split. If it is, I didn't manage to do it correctly, so maybe this is still useful to someone. No idea. In my own work, where I have wanted this, I have also wanted the captures associated with the pattern, so that might be a more useful contract than what is presented here.
Closes #681