Tracking Issue for deprecating std::ascii module

[clarfonthey]

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:

• Deprecation of std::ascii::AsciiExt: Deprecate the AsciiExt trait in favor of inherent methods #49109
• Implementation of u8::escape_ascii: Tracking Issue for inherent_ascii_escape #77174
• Deprecation of std::ascii::escape_default (not yet)
• Rename of std::ascii::EscapeDefault (not yet)
• Deprecation of std::ascii::EscapeDefault (not yet)
• Deprecation of full std::ascii module (not yet)

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?)

[dtolnay]

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