Skip to content

Tracking issue for str escaping #27791

@alexcrichton

Description

@alexcrichton
Member

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;

Activity

added
T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.
B-unstableBlocker: Implemented in the nightly compiler and unstable.
E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
on Aug 13, 2015
AnthonyBroadCrawford

AnthonyBroadCrawford commented on Sep 21, 2015

@AnthonyBroadCrawford

@alexcrichton Mind if I take this issue?

alexcrichton

alexcrichton commented on Sep 22, 2015

@alexcrichton
MemberAuthor

@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

Diggsey commented on Sep 22, 2015

@Diggsey
Contributor

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

bluss

bluss commented on Sep 23, 2015

@bluss
Member

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

Diggsey commented on Sep 23, 2015

@Diggsey
Contributor

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

bluss

bluss commented on Sep 23, 2015

@bluss
Member

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

removed
E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
on Oct 2, 2015
added
final-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.
and removed on Dec 16, 2015
alexcrichton

alexcrichton commented on Dec 17, 2015

@alexcrichton
MemberAuthor

🔔 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

BurntSushi commented on Jan 13, 2016

@BurntSushi
Member

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.

53 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    B-unstableBlocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCT-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.disposition-mergeThis issue / PR is in PFCP or FCP with a disposition to merge it.finished-final-comment-periodThe final comment period is finished for this PR / Issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @AnthonyBroadCrawford@alexcrichton@SimonSapin@Diggsey@BurntSushi

        Issue actions

          Tracking issue for str escaping · Issue #27791 · rust-lang/rust