SE-0200: "Raw" mode string literals

(Pedro José Pereira Vieito) #34


I think we should analyze this problem alongside with Regular Expression integration on Swift.

The r"" syntax does not feel Swifty at all. I would prefer something like #verbatimString("¯\_(ツ)_/¯").

Yes, Python includes exactly the proposed feature.

Read the proposal.

(John Holdsworth) #35

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.


(Chris Lattner) #36

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.


1 Like

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).

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.

(John Holdsworth) #39

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.


(Dale Buckley) #40

What is your evaluation of the proposal?

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?

Read the proposal and the thread.

(Michel Fortin) #41

What is your evaluation of the proposal?

I think it’s good. The need for raw string literals can be common in certain situations and having a simple syntax for them makes them simple to use.

I doubt this proposal will be enough though. There should be a way to include a double-quote in a raw string literal.

Is the problem being addressed significant enough to warrant a change to Swift?

I think it’s worth adding better support for raw strings.

Does this proposal fit well with the feel and direction of Swift?

Some people don’t like the r prefix. I don’t care much. A one-letter prefix has the advantage of keeping option opens for adding new forms of string literals in the future (we still have many letters to choose from). It’d be nicer if we could do without though, but I appreciate the number of non-alpabetic modifier characters available for this purpose is limited given that string literals are often adjacent to operators.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

The D language has many string literals, including one identical in syntax and semantics to this proposal. As far as I know, it’s very useful for file paths on Windows and regular expressions. If you need quotes inside a raw string in D, you can escalate to the delimited string literal which is more versatile but a bit more complicated to parse in your head.

Also, I don’t think all those string literals in D makes the language more complicated. It’s somewhat obvious what they are in context… except perhaps for D’s token string literal which doesn’t look like a string at all.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal.

(John Holdsworth) #42

New version of proposal

I’ve uploaded a modified version of this proposal here. The changes are that it modified the syntax of a raw literal to #raw(“a raw literal”) and it expands on the motivation and endeavours to rebut many of the common criticisms encountered thus far. If you have any comments on this version please let me know here while they can easily be changed.

I’ll file a PR on the new version tomorrow to swift-evolution and ask @Douglas_Gregor to merge and reset this review phase If possible. We’ll still have plenty of time to discuss it before the 26th.


1 Like
(Xiaodi Wu) #43

@johnno1962 I object; this seems highly irregular. Ideas should be pitched before they just go to review. I don’t see why this proposal is entirely circumventing that well-established process. I thought consensus had been reached to return to the pitch phase.

(John Holdsworth) #44

@xwu , I’m just trying to get things done. I thought Swift was supposed to be more of a Functional language than Procedural :grinning:. The passage of multi-line strings was far from well-established but has had a useful outcome to many.

It’s taken 5 months to make it this far and I think it’s good that this has come to review (perhaps prematurely) with a specific proposal as it has focused peoples minds a brought out specific objections and some better specific alternatives one of which I have adopted along with fleshing out the motivation and defences.

The prospect of going back to the pitch phase I don’t find attractive. The previous pitch got side tracked and I attempted to open such a discourse yesterday only to be greeted with radio silence. Let’s try not take a step back and get to a decision. If it’s “no" thats fine but at least this wouldn’t be hanging over me. I don’t want a repeat of the year long wait from multi-line string PR to release.


(Xiaodi Wu) #45

I, at least, have much to talk about that would be appropriate for a pitch. It sounds like others do as well.

The possible designs for string literals are many, and I would expect that a successful proposal would put in the legwork to explore the entire design space as completely as possible. It sounds like you’re trying explicitly to avoid such work. Again, I most strenuously object to such an approach.

(John Holdsworth) #46

Don’t hold back. The pitch thread is here: [Pitch] Raw mode string literals. It’s obvious the many PRs you and I have worked on I take a different approach to life than you do. I’d ask you to respect my way of working as I do yours. It’s up to the gatekeepers in the Core team to decide if this proposal can be brought back into review or not. If not, then fine I will persevere until progress can’t be made or it is clear there is no interest. For now I am just proposing ways forward. No need to get strenuous! I’m not trying to be unpleasant.

(Gwendal Roué) #47

I wish I would read much more welcoming answers. Little mistakes do not deserve such a tactless reaction. If you want to help, @xwu , guide @johnno1962 out of the trap.

(Xiaodi Wu) #48

Entirely so. I’m recording my objection to that course of action–not because I’m certain that I’ll be against the idea you’ve proposed, but because I’m communicating that I feel it’s important for the full and agreed-upon process for approving new ideas to take place. As you know, I felt this proposal to be rushed and incomplete to begin with; I would hate to see it fail not because of merits but because it’s being rushed again.

I can very much respect differences of opinion, but if your proposed “way of working” involves not going through the same process that others do in order to put forward their ideas, I must say that I cannot respect that and urge you to reconsider.

Yes, I can understand that objections are unpleasant. It’s not a commentary about how I feel about people, or in this case even the proposed idea. But I do strenuously object to the proposed course of action, which is irregular. Not sure how I can phrase that differently. @johnno1962 knows exactly what I believe to be the best way to proceed: returning to the pitch phase as others have mentioned. There is no trap, only more work to be done.

(Gwendal Roué) #49


Another solution is for @johnno1962 to revert his changes so that the review keeps on normally. You have no entitlemenr to judge a case alone, and force a return to the pitch phase.

I don’t expect much success of the proposal in its current form. Yet I expect a valuable conclusion. I, too, want the topic to move forward.

(Xiaodi Wu) #50

Sure, @johnno1962 can choose to do that as well. It’s my understanding that he wants to withdraw his proposal and have another go at it, instead of having it rejected formally after review (which is a barrier to bringing it back). It also seems sensible not to wait for a review and have a core team decision on a proposal that the author himself doesn’t want. I’m not forcing anything at all here.

(James Froggatt) #51

One use case for raw string literals is for strings which contain code. In this case, a delimiter of " (or even ")) isn’t ideal, since it may turn up in the string. Custom delimiters would be a great solution.

#raw(delimiter: "##", ##some.code("here")## )

The #raw ‘function’ could then have a default value for the delimiter, allowing for the simpler version quoted.

(Dave DeLong) #52

Oooooo, I really like this, especially with the “default value for the delimiter” bit.

1 Like
(Gwendal Roué) #53

Good to hear that you do not want to force anything. Now please give @johnno1962 the time he needs to decide, and eventually get other useful advice that help us all make progress.