Tracking Issue for inherent_ascii_escape

[clarfonthey]

Feature gate: #![feature(inherent_ascii_escape)]

Public API

impl u8 {
    pub fn escape_ascii(self) -> core::ascii::EscapeDefault;
}

impl [u8] {
    pub fn escape_ascii(&self) -> EscapeAscii<'_>;
}

// core::slice
pub struct EscapeAscii<'a>;

Steps / History

• Implementation: Add escape_ascii method to u8 and [u8] #73111 escape_ascii take 2 #83130
• Final commenting period (FCP)
• Stabilization PR

Unresolved Questions

• Naming. escape_ascii, escape_default, ascii_escape_default, ... ?
• Deprecate std::ascii::escape_default? (That is, all of std::ascii.)

[tanriol]

What's the status of this? Is it ready for stabilization or waiting for something?

[joshtriplett]

This seems reasonable to me, and it seems to work as advertised.

Shall we stabilize these escape_ascii() methods?

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge 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. 🔔

[clarfonthey]

One thing that wasn't mentioned in FCP: should stabilising this also lead to deprecating the std::ascii module? Since the naming seems to be fine re: the first unresolved question, but there's the one about deprecation as well.

[rfcbot]

The final comment period, with a disposition to merge, 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.

This will be merged soon.

[QuineDot]

Happy to see this land.

The documentation should

• link to escape_default or include the list of escapes inline
• mention that the iterator is over u8
• mention that it implements Display for those wishing to display escaped bytes without allocating (who aren't aware of the connection with ToString)

[clarfonthey]

Adding another comment to this, since there hasn't been a stabilisation PR: should stabilising this also deprecate the std::ascii module, since this is basically the last thing from that module that hasn't been moved over to an inherent method? I personally vote yes, but I understand if others disagree. Would rather not close this issue before an official decision is made, but that's also not my decision to make, so :p

[yaahc]

Nominated so we can make sure this gets discussed during our next libs-api team meeting on Wednesday.

[clarfonthey]

Also adding more details on what the deprecation would look like, for full clarity. When I say std here, that includes core as well.

1. Deprecate std::ascii module, std::ascii::EscapeDefault struct, and std::ascii::escape_default function.
2. Stably re-export std::ascii::EscapeDefault somewhere else. I vote putting it in std::num::EscapeAscii, but a case for putting it in std::char or std::str could probably be made.
3. Presumably, we want to move the implementations in std::ascii to their "permanent" locations and make the std::ascii module simply a re-export with a deprecation attribute.
4. One final thing to consider: is std::slice::EscapeAscii the right place for the slice-based iterator? There could be an argument for putting it in std::str instead, and then the single-byte version could go in std::char. Except, a version implemented for char would still just use the slice version, since chars can be multiple bytes. This bit isn't super important, but I feel that stabilising the method should still stabilise the iterator, so it can be embedded in structs easily.

[joshtriplett]

We discussed this in today's @rust-lang/libs-api meeting. We agreed that we don't want to treat std::ascii deprecation as a blocker; that should be a separate PR.

We'd love to see a stabilization PR for this feature.

[clarfonthey]

Opened stabilisation PR #93886 and tracking issue #93887 for discussing the deprecation of std::ascii, so that this can be closed post-stabilisation.

[clarfonthey]

("Implements" isn't on GitHub's close term list, but, this was merged.)