Skip to content
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

Stabilise inherent_ascii_escape (FCP in #77174) #93886

Merged
merged 2 commits into from
Feb 13, 2022

Conversation

clarfonthey
Copy link
Contributor

@clarfonthey clarfonthey commented Feb 11, 2022

Implements #77174, which completed its FCP.

This does not deprecate any existing methods or structs, as that is tracked in #93887. That stated, people should prefer using u8::escape_ascii to std::ascii::escape_default.

@rust-highfive
Copy link
Collaborator

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 11, 2022
@@ -804,7 +803,7 @@ impl u8 {
/// ```
#[must_use = "this returns the escaped byte as an iterator, \
without modifying the original"]
#[unstable(feature = "inherent_ascii_escape", issue = "77174")]
#[stable(feature = "inherent_ascii_escape", since = "1.60.0")]
#[inline]
pub fn escape_ascii(&self) -> ascii::EscapeDefault {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't really matter -- particularly with the inline annotation -- but it feels like this should take u8 rather than &u8.

I guess we've already FCP'd with this signature and changing the signature might cause some use sites to break at this point, but seems unfortunate.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an unfortunate side-effect of all the AsciiExt methods being moved to inherent versions while retaining the references. :(

Sadly, it's the most consistent with the other ASCII methods.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tracking issue FCP is actually for fn escape_ascii(self) -> ascii::EscapeDefault, and it looks like the original PR introducing these had a similar comment to mine requesting we use self (#73111 (comment))

I think we should update this to be self rather than &self prior to stabilizing it; consistency with other methods isn't really important.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh wow, that's 100% my bad. I'll make another PR to merge that change then rebase this on that. Not sure whether you'd wanna do a second FCP or just merge it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(rebase done, pending tests passing)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need a second FCP, I'm happy to r+ this PR directly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good to me! Figured I'd be safe just in case you wanted to wait a bit between the change and stabilisation.

Copy link

@jdahlstrom jdahlstrom Feb 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, self vs &self matters quite a bit when the method in question is passed as a function pointer, eg. to an iterator combinator. Having to eta expand Foo::bar to |x| x.bar() is a papercut, particularly if it's inconsistent.

@Mark-Simulacrum
Copy link
Member

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Feb 12, 2022

📌 Commit de6e973 has been approved by Mark-Simulacrum

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 12, 2022
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 13, 2022
…askrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#89926 (make `Instant::{duration_since, elapsed, sub}` saturating and remove workarounds)
 - rust-lang#90532 (More informative error message for E0015)
 - rust-lang#93810 (Improve chalk integration)
 - rust-lang#93851 (More practical examples for `Option::and_then` & `Result::and_then`)
 - rust-lang#93885 (bootstrap.py: Suggest disabling download-ci-llvm option if url fails to download)
 - rust-lang#93886 (Stabilise inherent_ascii_escape (FCP in rust-lang#77174))
 - rust-lang#93930 (add link to format_args! when mention it in docs)
 - rust-lang#93936 (Couple of driver cleanups)
 - rust-lang#93944 (Don't relabel to a team if there is already a team label)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 5699f68 into rust-lang:master Feb 13, 2022
@rustbot rustbot added this to the 1.60.0 milestone Feb 13, 2022
@clarfonthey clarfonthey deleted the stable_ascii_escape branch February 14, 2022 04:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants