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.

Sign up for GitHub

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

Jump to bottom

Tracking Issue for deprecating std::ascii module #93887

Closed
2 of 6 tasks
clarfonthey opened this issue Feb 11, 2022 · 1 comment
Closed
2 of 6 tasks

Tracking Issue for deprecating std::ascii module #93887

clarfonthey opened this issue Feb 11, 2022 · 1 comment
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@clarfonthey
Copy link
Contributor

clarfonthey commented Feb 11, 2022 •
edited
Loading

This is a separate issue to track the potential deprecation of the std::ascii, alloc::ascii, and core::ascii modules, separated from #77174 per this comment. This issue will just say std::ascii for simplicity since, excluding the already-deprecated AsciiExt trait, these three modules are identical.

Public API

Right now, std::ascii contains the following APIs:

  1. trait AsciiExt (already deprecated)
  2. fn escape_default(b: u8) -> std::ascii::EscapeDefault (now duplicated by inherent u8::escape_ascii)
  3. struct EscapeDefault (impl Iterator return value for escape_default, not re-exported anywhere)

The deprecation would involve:

  1. Deprecating fn escape_default (already moved to u8::escape_ascii)
  2. Re-exporting struct EscapeDefault somewhere else, presumably in std::num
  3. Deprecating struct EscapeDefault after its re-export is made stable
  4. Deprecating the entire std::ascii module

Steps / History

Some of these may involve separate FCPs:

Unresolved Questions

  • Where should std::ascii::EscapeDefault be moved to? std::num::EscapeAscii seems the most logical, but there could be other options.
  • What effects would this have on the larger ecosystem? (crater runs?)
@clarfonthey clarfonthey added C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Feb 11, 2022
This was referenced Feb 11, 2022
Closed
Merged
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Feb 13, 2022
@matthiaskrgr
Rollup merge of rust-lang#93886 - clarfonthey:stable_ascii_escape, r=…
5699f68 
…Mark-Simulacrum

Stabilise inherent_ascii_escape (FCP in rust-lang#77174)

Implements rust-lang#77174, which completed its FCP.

This does *not* deprecate any existing methods or structs, as that is tracked in rust-lang#93887. That stated, people should prefer using `u8::escape_ascii` to `std::ascii::escape_default`.
@clarfonthey clarfonthey mentioned this issue Mar 23, 2022
Closed
@dtolnay
Copy link
Member

dtolnay commented Apr 20, 2022

Closing per #95227 (review) — this is not something we are actively pursuing.

@dtolnay dtolnay closed this as completed Apr 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@dtolnay @clarfonthey