Uh oh!
There was an error while loading. Please reload this page.
Add unstable feature 'split_rinclusive', adding a right-inclusive version of str::split_inclusive - #90388
Add unstable feature 'split_rinclusive', adding a right-inclusive version of str::split_inclusive#90388logannc wants to merge 14 commits into
str::split_inclusive#90388Conversation
rust-highfive
commented
Oct 28, 2021
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @m-ou-se (or someone else) soon. Please see the contribution instructions for more information. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
logannc
commented
Oct 28, 2021
Sorry, didn't meant to use the CI as a testing platform. Thought this little afternoon PR was small enough I could skate by without figuring out x.py on Windows. If this one fails, I'll get things set up properly. |
This comment has been minimized.
This comment has been minimized.
logannc
commented
Oct 28, 2021
Hm, not sure what it means when the test targets time out. |
rust-log-analyzer
commented
Oct 29, 2021
The job Click to see the possible cause of the failure (guessed by this bot) |
joshtriplett
commented
Oct 30, 2021
Can you give some examples of use cases for this method? (I can imagine some myself, but I'd like to know what you had in mind.) |
logannc
commented
Nov 1, 2021
To be perfectly honest, I'm having trouble thinking of examples besides something like CamelCaseSplitting. I'm sure there are some formats which use sentinel values to indicate the start of a new section, but I'm not widely versed enough to name any. An argument could be made for symmetry between A sillier but still valid argument would be that I think there should be an easy way to split on caps without using Regex! Even if we include the iterator methods, its hard to implement. We can do it with Of course, we could also just implement such a thing imperatively, so it's not like we're stuck without it. :) Alternatively, I could see omitting this in favor of a dedicated function for it - it isn't an uncommon operation. But maybe this is just my own itch. |
joshtriplett
commented
Nov 2, 2021
CamelCase splitting and similar "records start with something that looks like this" formats seem like a reasonable use case. My main concern is the number of potential variations here: |
bors
commented
Nov 18, 2021
☔ The latest upstream changes (presumably #91019) made this pull request unmergeable. Please resolve the merge conflicts. |
JohnCSimon
commented
Jan 30, 2022
Ping from triage: |
JohnCSimon
commented
Mar 6, 2022
ping from triage: FYI: when a PR is ready for review, post a message containing |
JohnCSimon
commented
Mar 6, 2022
@rustbot author |
Apologies, no issue associated with this one. If that is necessary for a change this small, please let me know and I'll create an issue or pFCP as needed.
Motivation
str::split_inclusiveallows for easily splitting a string and including theseparatorin the substring on the "left".This change proposes
str::split_rinclusivewhich allows to easily split a string but include theseparatoron the "right".This does not change result order like
rsplit, so it is not, for example, a hypotheticalrsplit_inclusive. Actually, they might be somewhat inverses of each other, but telling people to usersplit_inclusive(...).rev()is less ergonomic and harder to reason about. Either way, neither currently exists.Implementation
For the most part, just copying the existing
SplitInternalimpl and changing the matcher indices used.We also introduce another param:
allow_leading_empty, an opposite to the existingallow_trailing_empty. This is to mirror the functionality ofsplit_inclusivewhen the final character matches (we do not return a trailing empty substring). Likewise, for this implementation, we do not return a leading empty string if the first character matches.