Tracking Issue for string_remove_matches

[jcotton42]

This is a tracking issue for string_remove_matches implemented in #71780
The feature gate for the issue is #![feature(string_remove_matches)].

• Stabilization PR (see instructions on rustc-dev-guide)
• Remove allocations (see discussion on Implement String::remove_matches #71780)

Implementation history

#50015 first attempt at this by @frewsxcv.

[frewsxcv]

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

[sciguy16]

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.

[andylizi]

Would it be possible to start an FCP for stabilising this feature? As long as we're happy with the public API

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.

[allaboutevemirolive]

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 remove_matches API is challenging to stabilize since it uses another unstable function, as discussed in this discussion (#27721)

Another thing is that it is much easier to avoid memory allocation when manipulating &str compared to String, since String is a heap-allocated data structure. Thus, developing memory-efficient functions for different types is challenging.

I think we probably need to make a separate function to remove patterns from strings, especially for the String type where optimization is needed.

[axeld-galadrim]

The main PR has been merged a few months ago.
Is it planned to move this feature as not experimental anytime soon ?