Implement RFC 2500 Needle API (Part 1)

[crlf0710]

This is a rebase of #59591 by @kennytm . As that PR is relatively large, i'm splitting it into a series smaller PRs.

This is the first PR in the series, which defines the core functions and traits. I've done the necessary changes like accounting for min_specialization, unsafe_op_in_unsafe_fn and i also documented all the unsafe blocks.

Since most of the code is not written by myself, the code should definitely needs more eyes on it.

Link to RFC 2500.

r? @Amanieu cc @withoutboats

[Amanieu]

I don't have the time to do much reviewing at the moment. Maybe @BurntSushi can take a look at this since this is related to regex?

[pickfire]

Maybe we should explain what is a consumer? I don't know if consumer can be an easy term to understand since there are many other ways that a consumer can be used, I wonder if there is a better term that can be used here.

[crlf0710]

I think i'll just link searcher and consumer to the corresponding trait...

[camelid]

r? @BurntSushi

[m-ou-se]

r? @KodrAus

[KodrAus]

I'll spend some time looking through this. I think there's a chance we'll want to try adopt a much simpler public interface for the API based on https://gist.github.com/rust-play/6f4932a58832875b81e37306cf6f16cd

[joshtriplett]

We discussed this in several recent @rust-lang/libs-api meetings, including last week and this week. This has been on our agenda for a long time.

We feel that this was originally proposed with the intention of providing integration between the standard library and (for instance) regex crates. It's become clearer, since then, that people seem fine using such functionality from regex crates rather than from the standard library.

Thus, we don't feel that we should add and stabilize this substantial additional API surface area.

We would instead propose sealing this trait, making it possible to name (if you want to accept instances of it in your own method that calls a standard library method) but not to implement for any type outside the standard library.

@rfcbot close

[rfcbot]

Team member @joshtriplett has proposed to close this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[jhwgh1968]

Since my attempt to ping the team over there didn't work, I'll just briefly mention that I hope this reverting of stabilization does not affect #49802 as well. I could really use several parts of that.

[inquisitivecrystal]

I'm sad to see this go. It's always seemed like opening this up would be really nice and make everything easier to work with. On the other hand, I'm not the one who would need to maintain it.

[rfcbot]

The final comment period, with a disposition to close, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

[Kixunil]

Sorry for late question, wouldn't sealing the trait prevent regex crates from existing? Am I missing something?

[inquisitivecrystal]

Sorry for late question, wouldn't sealing the trait prevent regex crates from existing? Am I missing something?

@Kixunil Nah, nothing like that. All it will do is prevent regex crates from being usable by standard library APIs. For instance, you'd need to type regex.split(string) instead of string.split(regex). This is actually the status quo. It had been planned to change it, but now those plans are being canceled.

[crlf0710]

Closing according to fcp decision above.
The next steps will be merging rust-lang/rfcs#3154