-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
B-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: 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.Relevant 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.This 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.The final comment period is finished for this PR / Issue.
Description
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;
Metadata
Metadata
Assignees
Labels
B-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: 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.Relevant 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.This 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.The final comment period is finished for this PR / Issue.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
AnthonyBroadCrawford commentedon Sep 21, 2015
@alexcrichton Mind if I take this issue?
alexcrichton commentedon Sep 22, 2015
@AnthonyBroadCrawford certainly! The workflow for this would probably look like:
Diggsey commentedon Sep 22, 2015
The reason given for why they're currently unstable says that they might be rewritten to return a char iterator instead?
bluss commentedon Sep 23, 2015
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 commentedon Sep 23, 2015
@bluss You can already do
.collect()
on a char iterator to turn it into a string.bluss commentedon Sep 23, 2015
True. With
Display
you can{}
-format the escaped string without intermediateString
or write-each-char loop.alexcrichton commentedon Dec 17, 2015
🔔 This issue is now entering its final comment period for stabilization 🔔
For now this FCP will be for returning a
String
as returning anIterator
which implementsDisplay
isn't found much elsewhere in the standard library, but FCP can help duke this out!BurntSushi commentedon Jan 13, 2016
Given that we have
char::escape_{default,unicode}
already stabilized, these seem like natural things to stabilize as well. I also agree with returningString
, 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 onchar
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