I think r"" is unfortunate because we do not yet have regex literals. I do not think that r is the best letter for this because of regex. I would rather have something more verbose like #verbatimString("") then once we decide how regex will be spelled then we can have shortcuts like @"" or #"" etc
Is the problem being addressed significant enough to warrant a change to Swift?
Yes. I love verbatim string in c# and I think I would use them a lot in swift if available.
Does this proposal fit well with the feel and direction of Swift?
yes. This name should be long to start with then we can shorten it once the regex syntax gets cooked.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
C#
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I am -1 on this proposal. While I agree that regular expressions are really suboptimal and need to be improved in Swift, this is the wrong direction IMO. I believe regex's are so important that we should introduce first class pattern matching syntax with industry standard // designators. Doing so is the tentative planned direction for strings and pattern matching already (as described in the recent string API discussions), which means that this feature is unnecessary over the long term.
The cost of this proposal is that it introduces clutter into the language for very little payoff. There are narrow cases outside the scope of regex literals (e.g. filepaths on windows) but these simply don't make the bar for me in terms of cost to add complexity to the language - there is no fundamental expressivity benefit being provided by this. We already have single quoted strings and multi-line strings, I'd rather not have a third string.
Yes, we need to introduce regex literals. Doing so will result in something much nicer than this proposal provides, because the existing NSRegularExpression APIs are also not very natural to use (e.g. because they operate in UTF-16 code points) and we can do better. This appears to be a stop-gap solution that only addresses one piece of the problem.
No. If not for the immediate problem with regex literals, I don't see a long term motivation. It also doesn't fit well with the existing Swift string model because it doesn't support interpolated values.
Yes, I've used C++ and other languages that lack regex literals and thus do something like this to improve the sugar. Those languages don't have pattern matching though, so there is little reason to build the regex literal support into the language. I've also used Perl which has waaaay too many kinds of strings, a mistake I'm not keen to repeat.
I read the proposal, but haven't followed the discussion thread.
Like many previous users have already commented, I feel the r"" spelling is inconsistent with the current direction of Swift.
Stepping back from the specific spelling proposed, I am not happy with the proposal for reasons that are similar to those articulated by @Chris_Lattner3. The general gist of my reply is that I feel that this proposal evinces no coherent vision for Swift's final design.
We already have two different spellings for literal strings, single-line and multi-line. This proposal wishes to add a third. Yet another discussion with positive feedback so far aims to add data literals as a fourth way of instantiating literal strings at compile-time.
It appears that we are adding new syntax at a high rate, piecemeal, and in this case to avoid escaping of one specific character. I agree with @Chris_Lattner3 (and others) that if the stated motivation is better support for regex, then we should have first-class support for regex literals. As far as providing a solution for that use case, this proposal doesn't go far enough for reasons that @Chris_Lattner3 has outlined, even as I feel it goes too far in terms of adding new syntax.
On a more meta level, I do believe that the bar for review of a proposal was consensus on this list during a pitch; I do not recall on consensus being reached for the design of this feature, and I am surprised to see it reviewed in proposal form.
This totally makes sense. If the use case is more or less confined to improving regex handling, or at least mostly inspired by it, it makes much more sense to tackle that problem directly instead of going the way of a stopgap solution.
First class regex support would be fantastic! I've been wanting to write a draft proposal on this for a while since it's been quite the pain-point for me, but I believe I lack the expertise to do so
My use cases for raw mode string literals are rare and far between and I can live without language support for them, but I really hope we will get proper regex literal support someday and the proposed raw mode string literal is not that.
So: I am -1 If you are proposing raw mode literals to avoid adding proper regex literals to the language in the future, .
Moderator note: this post has been edited to remove inadvertent self-promotion from an email signature that was incorrectly included by the post importer.
"The perfect is the enemy of the good."
I don't want raw strings to be side-lined while we wait for regular expressions.
The adage and your conclusion are not the same. Sometimes, the perfect is not attainable at all; therefore, it's folly to wait for it and reject the merely good.
"While we wait for regular expressions" is not a statement about attainability. You're advocating designs based on expediency, which is an altogether different statement. I don't think we should design new syntax based on expediency.
I totally agree string processing patterns deserve their own language support, but that's but one of many legit use cases for raw string literals. I think the functionality stands on its own independent of regexes as a specific motivating case. It's true Perl and Ruby have "many kinds of string", but that's far from the biggest complexity issue with those languages. Their many kinds of string were motivated by real use cases for scripting, and that's a domain we want Swift to be good for.
It would be nice, then, if proposal authors would have been so kind as to provide such legit use cases before the text was approved for formal review :/
regex is important and deserves first-class syntax
double-backslash in string literals is awkward and creates great quality-of-life problems for Swift users
I have been implementing a Parsing Expression Grammar library and found it impossible copy a standard PEG definition as a Swift string literal and feed it to my parser generator. Because PEG uses \ to escape characters.
There are more contexts in which \ plays the escape character role in a "guest language".
Now we can discuss whether this use-case is too rare to justify a language change. But there are other, popular languages that supports this case well. And I hope Swift would catch up.
That said, agree that r"" perhaps isn't the greatest syntax, and the meta-point that even if it was, the syntax deserved a wider discussion before it's poised for the formal review.
+1 on the feature, without particularly strong feelings.
To wit, many use cases beside regexes involve embedding another language in Swift code, such as:
Embedding a markup/templating language in code, a la JSX
Code generation, especially for languages for which a ready-made templating system or Swift DSL is not already available (e.g. try outputting LaTeX from Swift)
Making shell calls from Swift
These use cases are illustrative, not exhaustive. There will always be more occasions to embed a fragment of another language in Swift code, like @duan’s PEG example.
Ideally, whatever flag disables escaping, whether r, unescaped, or something else, would be orthogonal to single line / multiline and would in the future be applicable to triple-quoted strings as well. Edit: I see the proposal mentions multiline strings, which means that it also covers languages which make frequent use of ", so I'm all for the general idea.
That makes sense, but the proposal should encompass the motivating use cases. I'm just saying that IMO, as it stands, the proposal lacks motivating use cases outside of regex's, which can be solve in a better way. If you feel that there are other motivating cases, it would be great to work with the proposal author to strengthen the writing and make it more clear what the principle advantages of it are.
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?
I don't like cluttering the "non-identifier" namespace with another letter.
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 and implemented other languages supporting raw strings including binary data. The proposal lacks alternatives to discuss different approaches for the delimiter problem. (e.g. escaping, doubling, user-defined with assumption of non-occurrence).
My choice would be
Use single quotes (') as start and end delimiters, AFAIK they are not used yet (Xcode will just FIX it to double quotes).
Allow all binary values in between i.e. don't care about Unicode.
Replace two consecutive single quotes with one.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I read the proposal, most of the discussion and had implemented a scripting language with raw string support before.
Let’s not focus on Regular Expressions or the weakness of the proposal or “the meta” just yet and putting aside for a moment whether an independent case can be made for raw literals...
I suggest the thread deliberately put it’s bikeshedding hat firmly on and try to brainstorm up a single acceptable syntax on the basis of which the proposal can stand or fall. I’m not at all wedded to r”” syntax and, it has to be said, it does look like the result of a sneeze while typing.
My preference is now some variation on:
#raw(“this \a\b\c “is” valid”)
This is concise, more Swifty, and gives quite a bit of flexibility with a firm end delimiter of “). If this isn’t enough you can always drop down to raw triple quoted strings. Not so keen on the full #rawStringLiteral(“something”). This isn’t Java!
I also found this interesting:
\”a \r\a\w string”
It’s odd, and would likely provoke a google the first time you encountered it but strangely intuitive.
In the end though, if I can’t bring you round to a -0 Chris I’d rather withdraw the proposal.
Hi John, to be clear, my objection is to the proposal as written - not necessarily an objection to the idea of raw string literals themselves. Going back to the pitch / design discussion phase and trying again makes sense to me.
Chris is right, procedurally it is probably best to withdraw this proposal, and start a new “pitch” thread to discuss use-cases and possible syntax for raw string literal.
• • •
Just to get my thoughts written down though…
How about using single-quotes to demarcate *the delimiter*? That way it “looks like” you typed some text “inside” the double-quotes at each end of the string.
Although, to make the delimiters stand out, and to parallel multi-line strings, perhaps there should be three consecutive single-quotes (aka. triple single-quotes) around the custom delimiter.
Wait, better yet, make it three consecutive double-quotes around the delimiter:
let x = """customDelimiter"""
This is a raw string where \, ", and """ are preserved verbatim.
The leading-whitespace rule is the same as for multi-line strings.
There is no \(interpolation).
"""customDelimiter"""
Does that look reasonable? I don’t think we need a single-line version of this.
What is your evaluation of the proposal?
-1 from me in its current form.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes. Even outside of regex there are some use cases for raw strings.
Does this proposal fit well with the feel and direction of Swift?
No. The r"" syntax would feel incredibly alien in Swift. It's indirect, undescriptive and will certainly confuse newcomers to the language. Googling the syntax to find more information would also seem like a challenge.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Mainly in Python which uses the same syntax. Also the somewhat similar template strings in Javascript, which start and end with backticks (`).
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I read the full proposal.
I’ll concede I no longer stand behind syntax mentioned in the proposal as written and I auto-reject it if such a thing is possible.
There is an already existing “pitch phase” thread we could use rather than create another one: [Pitch] Raw mode string literals. I think we should keep this proposal thread open though and discuss syntax here as it has been far more focused than the pitch thread which went off on all sorts of tangents and was not conclusive.
Can we laser focus on what the syntax should be please and enumerate use cases and I can update the proposal for resubmission hopefully with someone who is a better writer of English than I is.
I was originally torn on this as it's something that affected me only the other day but I'm not a fan of the proposed syntax. After reading the thread I agree that RegEx needs to have it's own type, adding another string type is just going to add more confusion to the language. -1
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, it's definitely an issue that needs to be addressed, but not like this. The bigger picture needs to be taken into account here and a real solution to RegEx as a whole needs to be thought out.
Does this proposal fit well with the feel and direction of Swift?
No. Just adding syntactic sugar willy nilly is going to lead to a confusing mess and drive people away from the language instead of making people feel at home with it. We want the language to be predictable and not have outlying edge cases that you have to look up every 6 months when you forget how to use it each time.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
In some it fits, others it doesn't. It really depends on the language.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
