Reviews are an important part of the Swift evolution process. All reviews should be made in this thread on the Swift forums or, if you would like to keep your feedback private, directly in email to me as the review manager.
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
] Is the problem being addressed significant enough to warrant a change to Swift?
Yes.
] Does this proposal fit well with the feel and direction of Swift?
Pretty much. AFAIK, This is the first time we have a letter prefix to a " character. Some people might think "r" stands for "regex" but they probably wouldn't think that for long.
] If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Good.
] How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I find the concept interesting—a string literal wherein the backslash is just a normal character and there are no special behaviors. However, I am not a fan of the proposed spelling where “lowercase r, double quote” is the opening delimiter:
Any raw string literal syntax with fixed delimiters has the problem that you can't escape the delimiter. I'd prefer a design where the delimiter can be user-specified, so that anything can be embedded verbatim within a literal without escaping. There's lots of precedent for this—C++ has r"DELIMITER( )DELIMITER", Postgres has $DELIMITER$ $DELIMITER$, Ruby and Perl have their q operators which accept almost any following punctuator, shell has <<HERE\n .... HERE, and so on. I don't have a particular preference to which approach we take, but I think a user-controllable delimiter should be a requirement.
What is your evaluation of the proposal?
Looks good except I am not a fan of the r prefix. See below.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes
Does this proposal fit well with the feel and direction of Swift?
The simple r prefix takes Swift into the direction of scripting languages where single character modifiers change behavior. I don't think that's a good idea.
In general Swift makes a great effort to be inviting to newcomers and to be expressive. I don't think putting a single character in front of a string literal fits into this pattern.
Maybe (and that's just spitballing) #raw, or #unescaped, would make it more obvious how behavior changes. (Yeah, the # is already taken - I know). I am sure there are smarter people here who could come up with a better alternative.
The argument that python already uses the r character seems moot to me for the above reasons.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Perl or sed comes to mind ::shudders::
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Read through the proposal
I like the conciseness of the r"" syntax, but I feel it is fairly inconsistent with how other things in Swift are done.
Does this proposal fit well with the feel and direction of Swift?
I agree with @tkrajacic , I wonder if it would be more clear using a similar syntax as #imageLiteral(), maybe #rawString()
Ruby also has a % operator that still allows string interpolation, but escapes other characters for you. Using the #rawLiteral syntax may give the ability to later add features such as this if desired in a way that's clear of its intentions.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Similar concept to other languages. The feature itself I like.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
We do need a syntax for raw-mode string literals, but it should address the above issue. It will be almost useless for me if I can't have double-quotes in a raw literal string.
Avoid abbreviations. Abbreviations, especially non-standard ones, are effectively terms-of-art, because understanding depends on correctly translating them into their non-abbreviated forms.
The intended meaning for any abbreviation you use should be easily found by a web search.
As well as being an abbreviation that would be difficult to find the meaning of in a web search, seeing r"a string" in source code would look like a stray mis-entered character to me. I would personally prefer some notation that was an explicit and expressive word like unescaped or raw preceding the String literal quotes. Even better would be something that look like existing Swift syntax like raw("string literal") or #raw("string literal") rather than characters that look like they might have unintentionally been typed outside the beginning of the string.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, I think so. It's a nice feature to have.
Does this proposal fit well with the feel and direction of Swift?
I'm not sold on the "r" prefix; it just doesn't look particularly "Swifty" to me. I liked the idea to use the existing literal syntax, so how about #rawLiteral()? If we were to include @Joe_Groff's custom delimiters, it might look like this: #rawLiteral(delimiter: DELIMITER, value: DELIMITERthis is a raw stringDELIMITER).
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I've seen them in C++, Python, and Bash, and this closely matches the Python syntax. As I've said above, though, I don't really think we should be striving for this.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Read the proposal and the comments in this review thread.
What is your evaluation of the proposal?
+1 for the idea, but -1 for the r"" syntax
What about using \"" instead?
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, I think it is very important for things like regex, where you currently have to alter regexes from other sources to work. The \\ everywhere also makes things less readable.
Does this proposal fit well with the feel and direction of Swift?
The idea is good, but the proposed syntax doesn't feel swifty™
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I haven't
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I read the proposal
I like it -- I think it would be a valuable addition to the language.
Is the problem being addressed significant enough to warrant a change to Swift?
I believe so.
Does this proposal fit well with the feel and direction of Swift?
Although the r prefix doesn't have a precedent in Swift (as far as I know), I think it's a nice and effective syntax. It feels like a natural direction for the language to go.
I agree with Joe that support for custom delimiters is important. Would there be any issue with allowing the user to use an arbitrary prefix in place of r while also using it as a suffix?
mydelimiter"here's a "raw string" with a custom delimiter"mydelimiter
r could be a special prefix that isn't required to be suffixed, which I think would make the proposed syntax a nice, consistent default.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I have limited experience with this feature in other languages (so take my input with a grain of salt).
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Read the proposal and the discussion up to this point.
I'm in favor of the idea, and I like the r"" syntax. I have lots of experience with the same feature in Python and it works really well.
Having said that, I'd prefer that the proposal made it more clear what the rules are about leading whitespace, since the multi-line r""" example implies there is some non-trivial processing going on.
What is your evaluation of the proposal?
I like the idea, the examples provided in the proposal give good justification for the change to be made.
Is the problem being addressed significant enough to warrant a change to Swift?
I think so.
Does this proposal fit well with the feel and direction of Swift?
I think the problem that this proposal is trying to solve is definitely worth implementing, but I again agree with @tkrajacic that the r syntax is not clear. Something similar to #rawString would make usage easer to understand.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Similar concept to Python's r strings, although Python also uses other single character modifiers such as f to provide string interpolation:
age = 42
print(f"They are {age} years old")
This is obviously handled completely differently in Swift, requiring no character modifier. Requiring r for raw strings may seem confusing.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A read of the proposal
Since it seems to be bikeshedding day, I'd probably prefer the wordy #rawStringLiteral() over r"", \"", or whatever. Of course, then you have to worry about the closing parenthesis, and whether the literal is quoted, and how to use literals for internal parens and quotes, but waves hands that's just an implementation issue. The advantage of #rawStringLiteral is that it follows an existing Swift naming pattern and that it's self explanatory in what it's trying to do.
I personally never missed raw string literals, and I dislike the syntax for reasons others already expressed.
The first may change in the future, but I doubt that I'd ever like r"".
But for me, the strongest argument against this addition is the lack of a big picture:
Swift evolution favors small steps, but sometimes, those can lead to chaos.
The proposal states that the new literal might be used for regex, but there's no clear vision how this topic will be handled in Swift.
Imho such fundamental yet tiny changes to the syntax shouldn't be decided in full isolation.
Besides the regex-question, there's also yet to be decided wether single quotes will get a special meaning...
I stumble across escaping slashes every time I do something involving regular expressions and have wished for something like this a few times. Definitely a welcome addition on my end.
r"foobar" is understandable imo, especially if the user has seen similar things in other languages before. A bit more fitting with current Swift syntax would be the aforementioned #raw"foobar" or similar. I'm personally not the biggest fan of the very wordy alternatives and would prefer to keep it short, albeit being more expressive than a simple r"foobar" doesn't seem to be a bad idea.
My vote goes towards #raw"foobar".
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, as said before I've run into the problems this proposal aims to solve several times.
Does this proposal fit well with the feel and direction of Swift?
Yes.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Works great in other languages
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
