RFC: add raw_str macro for strings with no interpolation/unescaping #19900
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
KristofferC
approved these changes
Jan 6, 2017
StefanKarpinski
approved these changes
Jan 6, 2017
vtjnash
approved these changes
Jan 6, 2017
stevengj
reviewed
Jan 6, 2017
| Raw strings without interpolation or unescaping can be expressed with | ||
| non-standard string literals of the form `raw"..."`. Raw string literals | ||
| create ordinary `String` objects which contain the enclosed contents exactly | ||
| as entered with no interpolation or unescaping. This is useful for strings which |
There was a problem hiding this comment.
The exception is quotation marks, which are still escaped, e.g. raw"\"" is equivalent to "\""
There was a problem hiding this comment.
won't get addressed if it remains a comment on a closed pr. open an issue or pr?
There was a problem hiding this comment.
Updated documentation to note exception in #20239
|
Thanks for revisiting this! As Kristoffer mentioned in the previous version of this PR, this is very well thought out. It's an exceptional first contribution to Julia. Nice work! |
|
Should this go into News.md? Looks quite useful. |
This was referenced Jan 26, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This implements a raw_str macro that allows input of strings with no interpolation/unescaping as discussed in issue #11567 and #11764. I understand this functionality (as
L_str) was removed by commit 7123ad3 following discussion in issue #107. However, I think this merits reconsideration for a couple reasons.This feature is useful as a base for working with strings that represent code/markup in other languages. This is reimplemented in packages that deal with these situations, e.g. LaTeXStrings, but the core functionality seems sufficiently general to merit inclusion in base.
Although the implementation of raw_str is basically trivial, it has very low discoverability to new users, especially people coming from python who expect to have the functionality builtin. Users wanting to use raw strings shouldn't have to go through stack overflow to implement this functionality themselves.
raw_str is clear, concise and provides a useful base for more complicated use cases. Because raw_str doesn't unescape anything, it is possible to define exactly what you want to unescape in julia, e.g.
unescape(raw"...")will unescape traditional c/unicode escape sequences but leave $ escaped and avoid interpolation. This seems much cleaner than some proposals for using string macro suffixes to specify exactly what to unescape. Also to meraw"..."seems more self-documenting thanL"..."or'''...'''and adds the minimal amount of additional complexity to the strings ecosystem.Apologies in advanced if this has already been hashed out beyond the discussions I was able to find, but given the two open issues I thought it was worth submitting a PR to see if we can figure out something that can be merged into master.
This duplicates PR #19254 which I closed/deleted because there was no response so I assumed there wasn't interest. However, since closing that PR it seems that there is at least some interest so I am creating this new PR. Unfortunately I can't reopen the old one because the branch is deleted. Apologies for the clutter.