-
Notifications
You must be signed in to change notification settings - Fork 12.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking Issue for string_remove_matches
#72826
Comments
Can we add a note in the Issue description mentioning we should remove allocations from the current implementation? Not necessarily a blocker to stabilizing, mostly to document the discussion we had in #71780 |
Would it be possible to start an FCP for stabilising this feature? As long as we're happy with the public API, optimising the implementation to reduce/remove allocations can be done post-stabilisation. |
According to the discussion in #71780, the current API is considered too restrictive. Improving it would depend on redesigning the Pattern API, so this probably won't be stabilized anytime soon. |
Hi, novice here. I have read the discussion in (#71780) and understand that the current API has memory allocation and they want to remove HRTB. I'm curious: why not just design the current API to yield back strings that don't have the same pattern if we really don't want memory allocation, thus simplifying ownership and borrowing? Edit: After further analysis, I found that the current Another thing is that it is much easier to avoid memory allocation when manipulating I think we probably need to make a separate function to remove patterns from strings, especially for the |
The main PR has been merged a few months ago. |
This is a tracking issue for
string_remove_matches
implemented in #71780The feature gate for the issue is
#![feature(string_remove_matches)]
.Implementation history
#50015 first attempt at this by @frewsxcv.
The text was updated successfully, but these errors were encountered: