Tracking issue for str escaping

[alexcrichton]

This is a tracking issue for the unstable str_escape feature in the standard library. The open questions I know of here are:

• Do we want to support these relatively arbitrary ways to escape strings? Note that these same methods for escaping characters are already stable.
• Are the precise forms of escaping stable? (probably because they delegate to char implementations)

I suspect that because the implementations on char are stable that we'll also stabilize these.

Signatures:

String::escape_debug(&self) -> String;
String::escape_default(&self) -> String;
String::escape_unicode(&self) -> String;

[AnthonyBroadCrawford]

@alexcrichton Mind if I take this issue?

[alexcrichton]

@AnthonyBroadCrawford certainly! The workflow for this would probably look like:

• Come up with a story for these methods, e.g. should they be stabilized as-is or tweaked?
• Gain feedback about that state of affairs (e.g. IRC, reddit, forums, etc).
• If large enough, write an RFC
• Write a PR
• Stabilize in the next cycle.

[Diggsey]

The reason given for why they're currently unstable says that they might be rewritten to return a char iterator instead?

[bluss]

Maybe we can consider the idea of them returning iterators, but those iterators implementing Display. That makes it easy to use them composably (without having to allocate a string) while also having the string available (the .to_string() method).

[Diggsey]

@bluss You can already do .collect() on a char iterator to turn it into a string.

[bluss]

True. With Display you can {}-format the escaped string without intermediate String or write-each-char loop.

[alexcrichton]

🔔 This issue is now entering its final comment period for stabilization 🔔

For now this FCP will be for returning a String as returning an Iterator which implements Display isn't found much elsewhere in the standard library, but FCP can help duke this out!

[BurntSushi]

Given that we have char::escape_{default,unicode} already stabilized, these seem like natural things to stabilize as well. I also agree with returning String, because that's probably what you'll use most of the time. If the extra allocation really matters, then expecting the programmer to build the iterator themselves with the underlying methods on char seems pretty reasonable IMO.

I do admit that I find it strange that these methods are in std, but I have found them occasionally very useful.