or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
Proposal link:
Reply text
Other replies
What goes into a review?
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?
More information about the Swift evolution process is available at:
Long strings are strings delimited by """triple quotes""" that can contain newlines and individual " characters without the need to escape them.
Are the set of backslash-escapes inside a long string identical to the set used in short strings? I assume that \" inside a long string is interpreted as an escaped double-quote; otherwise there would be no way to write """ inside a long string.
To allow free formatting of the literal an indentation stripping operation is applied whereby any whitespace characters in front of the closing delimiter are removed from each of the lines in the literal. As part of this process any initial linefeed is also removed. This allows the developer to paste literal content directly into the string without modification. Some concern has been expressed about could introduce confusion if the prefixing indentation of each line does not contain the same whitespace characters, though this can be checked for by a compiler warning.
To clarify, is this the intended algorithm?
if the source code of the closing delimiter matches regex(\n\s+""") {
collect the sequence of whitespace characters between the newline and the delimiter
remove exactly that sequence of characters, if present, from the front of each source-code line after the line containing the opening delimiter
if a line does not start with those characters, emit a warning
}
···
On Apr 6, 2017, at 12:35 PM, Joe Groff <jgroff@apple.com> wrote:
I support the initiative. But I have the question as Greg and Tony: how would one write “”” in side the literal?
• 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?
Yes.
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I like stealing from Python.
I particularly like the whitespace striping algorithm. In Python, multiline literal is often awkward because the literal gets mixed up with whitespaces from indentation, when programmer adjust for that, the body of the literal breaks the indentation and looks jarring.
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I like the feature a lot, but I'm not so sure about the described indentation-stripping behavior. I don't think that putting the closing """ at the same indentation level as the string's contents is very intuitive. It feels a bit like writing this:
if someCondition {
print("message")
}
In general, the closing delimiter in a multiline context (for lack of a better general term) is indented to the same level as the line that contains the opening delimiter, so I think that unless developers are explicitly taught otherwise, they would likely default to that style for multiline strings, resulting in confusion about why there's an extra level of indentation in the interpreted multiline string.
I think what would be more intuitive and stylistically flexible would be to strip the largest amount leading whitespace that is common to each line. In other words, whichever line(s) that have the least amount of leading whitespace would determine the amount of indentation that gets stripped.
Apologies if this approach has been discussed before -- I missed most of the discussion that led to the proposal. Any thoughts on this?
• Is the problem being addressed significant enough to warrant a change to Swift?
Yes -- this would be a very useful feature in some situations.
• Does this proposal fit well with the feel and direction of Swift?
I think so.
• 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 used this feature enough in other languages to comment here.
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I read the proposal thoroughly.
Jarod
···
On Apr 6, 2017, 12:35 -0700, Joe Groff via swift-evolution <swift-evolution@swift.org>, wrote:
Hello Swift community,
The review of SE-0168 "Multi-Line String Literals" begins now and runs through April 12, 2017. The proposal is available here:
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
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?
More information about the Swift evolution process is available at:
+1
We definitely need a multi-line string solution, and I’m a fan of the python-like “”” solution.
• 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?
Yes
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Favorably.
This is Largely the same as python, with the addition of leading-space stripping, the lack of which is one of the biggest gripes I’ve had and seen with python’s “”” implementation.
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Followed both the original discussion and the recent revival closely.
···
On Apr 6, 2017, at 2:35 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
More information about the Swift evolution process is available at:
• Is the problem being addressed significant enough to warrant a change to Swift?
As I had said before, it has to be simple and take care of most cases. I wanted a continuation character but some people expressed being able to copy/paste right into the editor without much formatting. And not having a continuation character will make this possible.
I think that using the closing triple quote to control how much indentation to remove from the previous lines is good enough.
String interpolation will be supported and I assume escaping of characters too. So if someone wanted to embed a triple quote then they would have to escape the first one I'm guessing, ie. \""". Although I am not that concerned because triple quotes is super rare in my use cases.
Being able to include quotes without having to escape them is also good as that was one of my main concerns.
• Does this proposal fit well with the feel and direction of Swift?
I think it does.
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Well java uses the concatenation. This would be superior. Other languages use "line 1" then on the next line you start with "line 2", and so on. This would be superior as well because you can copy / paste right into the editor and be productive with minor formatting. It will also allow quotes in the string.
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Participated in the discussion and shared my ideas and goals for this feature.
···
On Apr 6, 2017, at 3:35 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
More information about the Swift evolution process is available at:
In terms of the overarching theme, I think it is delightful.
But I am very disappointed that this proposal did not first circulate as a
draft in the past few months prior to being sent out for review. I
understand that it is an abbreviated timeline for evolution, but there are
key elements missing from this proposal that need clarification before it
can properly be reviewed. Greg Parker covers some important questions, but
there are others too:
1. The proposal states that "any initial linefeed" is stripped:
- Is that one initial linefeed, or arbitrarily many initial linefeeds?
- Is that only LF, or also CR and/or CRLF?
- How about trailing LF, CR, and/or CRLF?
- If trailing LF/CR/CRLF is stripped, is it only one or arbitrarily
many?
- If arbitrarily many, would one have to escape trailing LF to avoid
such stripping (as in, `\n`)?
- If none are stripped, then how can one choose to specify the correct
indentation without the string obligatorily ending with an LF/CR/CRLF?
2. The proposal mentions breaking lines throughout and the term "linefeed"
only once. How are line endings treated?
- If they are normalized, is it to LF?
- If they are not normalized, how do you propose to have this interact with
git's recommended "core.autocrlf" setting, which will automatically change
your literal string if it's checked out on a different platform? (See: Configuring Git to handle line endings - GitHub Docs)
• 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?
Yes--well, it needs more detail to be a fully fleshed-out proposal.
• If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?
Yes--and to answer the question about how this compares, we need more
detail.
• How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
I have thought about this off and on for quite some time.
or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:
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?
+0.75. I think the language needs a good facility to support multi-line
string literals in code, and the Python triple-quote syntax is the cleanest
of all the ones I've used among various languages.
I would like to see some more detail/clarification in the proposal before I
could give it a full +1 though:
1. The proposal shows that double quotes don't need to be escaped in these
literals; similarly, string interpolation is supported with the usual
\(...) syntax. How is escaping of other characters handled within these
strings? Is it affected or not? If I include \n in my multi-line string,
does that insert a newline at that location, or is it the literal "\n"? (I
expect the former, but I'd like to see it spelled out.)
2. If I want to be terrible and include the literal """ in the content of
my string, how would I escape that? Is \"\"\" sufficient/the only way/the
right way? Does it make a difference if it's leading the line (with the
exception of whitespace) or in the middle of a line?
3. Deciding how much leading whitespace to strip based on the indentation
of the *closing* quotes seems a bit strange/magical to me, but I honestly
can't think of a cleaner way to do it. This at least makes the amount of
leading space something that I can explicitly control (and IDEs like Xcode
could color in the margin accordingly to make it clear how much of the
leading space is actually part of the string).
• Is the problem being addressed significant enough to warrant a change to
Swift?
Yes. While Apple platforms can just load large strings from bundled
resources, that doesn't support string interpolation, and non-Apple
platforms can also benefit from this feature.
• 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?
It lines up most closely with Python's multi-line strings, which I prefer
to shell-style heredocs with arbitrary begin-end tokens.
• How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
Read the proposal.
···
On Thu, Apr 6, 2017 at 12:35 PM Joe Groff via swift-evolution < swift-evolution@swift.org> wrote:
More information about the Swift evolution process is available at:
I'm a -1 for several reasons, mostly subjective but still. First thing is that I'm generally not comfortable with encouraging the use of multi-line strings at all. These are things that usually should be templated or localised, and personally I don't see what's inconvenient about concatenating on those occasions where you can't (or just don't want to); I'm actually of the opinion that this is the kind of thing that should be awkward and annoying, to encourage developers to think about what they're doing.
My second issue really is that, if the aim is simply to indent your multi-line string more nicely, then is this actually something that the language has to solve? I know we don't like to consider proposals purely from the perspective of what an IDE may, or may not, do, but this seems like a case where a good IDE could take:
let foo = "This is my
multi-line
text"
And display it visually to look like:
let foo = "This is my
multi-line
text"
This is basically what Xcode does for line-wrapped text right now. While it would mean people using more basic editors would still see the original, it's not really like that's a major problem.
Another alternative might be a compiler directive that is more explicit about what you want to do, for example:
let foo = #trimleft("
This is my
multi-line
text
")
Here the directive would look at the text as a whole and see that all lines are indented by at least one tab, and so strip one tab from each line. There's probably a better name for the directive, but hopefully you hopefully get the idea, as this is much more explicit about what you want to do.
Also, one thing that really stands out with the proposal is how unwise the example is; the fact that the assertion relies on leading whitespace being stripped from the multi-line HTML makes it clear why things like this may not be a good idea, as if the code is edited to produce indented HTML then the assertion will fail, even if the HTML is still correct. The continuation quotes example makes this more obvious as it actually include some of the whitespace, so which is correct?
I don't want to seem too negative, I just think that whitespace stripping multi-line strings are a weird thing to want in a language. If an easier multi-line syntax has to be added then my preference would be for the alternative continuation quotes personally, as it's more explicit about what is included, though I still say there's nothing wrong with just doing the concatenation and newline characters IMO, as it's fully supported today and not really that much more burdensome to do (and it being a bit more difficult may be a good thing, as I say).
• Is the problem being addressed significant enough to warrant a change to Swift?
Not really. We can already do multi-line by either putting newlines inside quotes and leaving out indentation, or by concatenating lines terminated with the new-line character. IMO these two existing options are enough as it is.
• Does this proposal fit well with the feel and direction of Swift?
I'm not sure; in terms of simplicity I think that adding new syntax for multi-line strings is an unnecessary added complexity and something else to learn, and doesn't enable anything we can't already do fairly easily.
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
All of the proposed syntaxes are present in various languages, I've used many of them, and I know from my own bad habits that 99% of the time I shouldn't have
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Followed the discussion and re-read the proposal.
···
On 6 Apr 2017, at 20:35, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
Strong +1. Of all the ideas and proposals for multi-line string literals, this version is my favourite. Supporting copy/pasting and easy editing of multi-line strings is so important that I’m very happy the continuation quotes idea for dismissed.
• Is the problem being addressed significant enough to warrant a change to Swift?
Oh yes!
• Does this proposal fit well with the feel and direction of Swift?
It does for me.
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
It compares favourably.
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Followed most discussions about multi-line strings.
Can opening and closing """ be on the same line?
I.e. :
print("""is text allowed here?
text
""");
print("""
text
and there?""");
print("""allowed?""");
What line-end characters will be actually added at the end of each line?
( '\r' ? '\n' ? "\r\n" ? other ? )
Sometimes it can be important what char(s) is a marker of the line end for the code that *receives* our multi-line string.
How to paste """ inside a multi-line string ?
How to paste these two symbols \( inside a multi-line string (i.e. just symbols, not beginning of string interpolation block) ?
Should single backslash be escaped ?
···
On 06.04.2017 22:35, Joe Groff via swift-evolution wrote:
Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at:
or, if you would like to keep your feedback private, directly to the review
manager. When replying, please try to keep the proposal link at the top of
the message:
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?
More information about the Swift evolution process is available at:
The first questions that pop into mind are "how do I write the character sequence """? And the literal \(something)?".
But if you think twice, those sequences would need to be escaped just like now with the existing simple string literals. So in the end if you know how to escape in a one-line literal, you know how to escape in a multi-line literal.
• Is the problem being addressed significant enough to warrant a change to Swift?
Yes. Though I would use it not every day, sometimes I really need this syntax and I would have loved to have it. Also, from my own experience, this is even more important for server-side Swift apps.
• 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?
Very favorably, I think it trumps any other option that I've known and used, even some template languages.
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I've followed the discussion and read the (small) proposal.
···
On Thu, Apr 6, 2017 at 9:35 PM Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
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?
A firm +1. This is an important feature for a number of different use cases. I should note that improving ergonomics for scripting, testing, and knocking together quick sample code are goals in themselves, even if you feel it would be bad to include big gobs of string literal in “real” code – you can simply ignore this feature if you feel it’s inappropriate in that use case. Unlike, say, adding keywords, it does not expand the overall surface area of the language in a way that will harm existing use or be confusing to people encountering it for the first time.
I understand the concerns re clarifying the exact behavior. I think these are more assumptions that need to be explicitly documented than flaws that would block accepting the proposal once those clarifications are added and circulated.
• Is the problem being addressed significant enough to warrant a change to Swift?
Yes. I find myself wanting this on a regular basis.
• Does this proposal fit well with the feel and direction of Swift?
Yes, and also fits well with the current focus on String improvements in Swift 4.
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Of the various different options from different languages, I feel this is the best. The syntax is lightweight, which is important. The ability to cut+paste* text directly is a big win over continuation quotes, which I find fiddly to maintain and ugly to read. I like the ability to indent, especially for scripting. Triple quotes are simpler than heredoc, including for new users.
*most text – I don’t think code including specific cases like including triple-quotes or other escaped values is a showstopper, so long as these exceptions are explicitly called out.
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A fair amount.
···
On Apr 6, 2017, at 12:35 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
More information about the Swift evolution process is available at:
It is good, but incomplete, needs many clarifications, and could be well improved with visual examples.
Some questions:
- What's the destiny of \", \n, \t, etc? Saying that single quote don't need to be escaped is not enough.
- The sentence "This allows the developer to paste literal content directly into the string without modification" is confusing, to say the least. I guess I can't paste a literal that contains a triple quote """, for example. Other languages don't use triple-quoted strings for heredocs (which, unlike triple-quoted strings, do support blind pasting: https://en.wikipedia.org/wiki/Here_document\).
- What *exactly* happens to leading and trailing newlines?
- Can we have white space characters at the end of a line in the middle of a multi-line string? Doesn't it need tooling support? (Xcode usually deletes trailing white spaces)
- Oddly enough, I don't read "Python" in the proposal. Since Python has triple-quoted strings, it may be a good idea to use their experience.
I finally suggest that the proposal comes with a detailed list of examples, including examples of *corner cases*. Readers with a visual mind will enjoy *seeing* what happens. To list a few examples where I expect the output to always be "foo", but I'm not 100%sure:
- """foo"""
- """foo
"""
- """foo
"""
- """
foo"""
- """
foo
"""
- """
foo
"""
- """
foo
"""
- """
foo
"""
I'm not asking answers to the above questions in order to feed the future Swift documentation - I need those answers in order to be able to evaluate the proposal.
Is the problem being addressed significant enough to warrant a change to Swift?
Oh, yes! The String + operator is nice, but not enough!
Does this proposal fit well with the feel and direction of Swift?
I guess it does.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
It's OK, but still lacks clarity.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Enough to get many questions.
Thanks for the proposal,
Gwendal Roué
···
Le 6 avr. 2017 à 21:35, Joe Groff via swift-evolution <swift-evolution@swift.org> a écrit :
Hello Swift community,
The review of SE-0168 "Multi-Line String Literals" begins now and runs through April 12, 2017. The proposal is available here:
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
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?
More information about the Swift evolution process is available at:
Is the problem being addressed significant enough to warrant a change to Swift?
I don't necessarily think that the concept is a bad idea, but I think that the interaction of Swift features facilitates poor coding decisions. For example, the proposal interpolates an `author` variable straight into an XML document, and suggests doing the same to JSON strings. To me, this shows that an important use case of the feature is to format payloads in a way that is known to cause vulnerabilities.
Of course, you can already shoot yourself in the foot that way with short strings, but at least, it looks ugly. Come up with a solution that looks better and people will stop using the ugly one. The long string version looks good despite being dangerous, and I think that it would compete with safe efforts.
You can also say that it's the developer's responsibility to make sure that you don't misuse it. I disagree. I think that SQL injections and the like have caused enough damage that it's time to change attitudes.
To be clear, I wouldn't be opposed to large strings that can't interpolate (but I don't think that they would be extremely useful).
Does this proposal fit well with the feel and direction of Swift?
I think that it's a secondary concern. There are better, type-safe, and not much more cumbersome ways to create XML and JSON documents that don't open careless developers to injection vulnerabilities, which are much more Swift-like ways to solve that problem. I would rather have the community work on that kind of solution than to make strings look like the right tool.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
If you remove interpolation support from long strings, they aren't particularly compelling anymore. I use long strings in Python for documentation and not much else; but Swift uses comments for documentation. There are just not that many places where you need long strings outside of quick-and-dirty payload formatting, and printing your --help message (assuming that the community doesn't come up with a great option parsing library, if that doesn't already exist).
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I've done enough reading to know that my opinion is unpopular. :)
···
Le 6 avr. 2017 à 12:35, Joe Groff via swift-evolution <swift-evolution@swift.org> a écrit :
Hello Swift community,
The review of SE-0168 "Multi-Line String Literals" begins now and runs through April 12, 2017. The proposal is available here:
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
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?
More information about the Swift evolution process is available at:
-1. I don’t feel this properly solves all the issues of multiline strings. Indeed, I think the baked-in whitespace-stripping would complicate or preclude its usage in some scenarios.
Languages with multi-line string primitives typically have to bake in multiple approaches and/or behavioral modifiers to meet all the use cases. This appears to aim for a very particular behaviors with regards to formatting and whitespace, without proposing ways to support other behaviors. As the motivation section did not attempt to summarize the expressed desired behaviors, the swift-evolution threads are the best place to go to determine the conflicting sets of desired behaviors.
Likewise, it feels underspecified. For example, the specification does not detail what the behavior is of
let a = """foobar""" // legal? equivalent of "foobar"? Would you get a warning?
let b = """""" // legal? equivalent of "" ? Would you get a warning?
let c = """multi-line strings are escaped using the """ (triple-quote) characters""" // legal? does the triple quote need to be escaped?
I feel that some of the alternate approaches were discarded for rather arbitrary reasons as well(regex-based syntax formatter issues?), and suspect this approach was chosen for its ease of copy/pasting in text. However, I understand the desire to have just a single proposed approach - I just don't feel thats realistic for the wide variety of requirements expressed in discussions.
• Is the problem being addressed significant enough to warrant a change to Swift?
Absolutely. I feel however that discussions have not resulted in a single approach being deemed more appropriate than others.
• Does this proposal fit well with the feel and direction of Swift?
I don't think so as specified - it simply does not cover enough of the given desired functionality.
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
This seems closest to how multi-line strings work in python (which some refer to as its heredoc support). However, python multi-line strings both are simpler by default and have more optional complexity:
- Multi-line strings in python by default include the initial newline and all indentation. There is a syntax """\ for indicating that the newline following the starting quotes
- As a more general pattern, each line of a multi-line string ending in a backslash squelches the newline character
- Python does not (from my memory) have any way to eliminate indentation. The expectation is that the embedded text starts at column 0.
Python includes other methods to do strings across multiple lines, such as:
- ("foo" <newline> "bar") # results in "foobar", the strict concatenation of the two strings
- "foo\<newline>bar" # also results in foobar, as the newline is squelched by the backslash before the newline.
I'm personally most familiar with the support in Ruby, which has an even more comprehensive set of options and controls - single and double quotes as well as custom quoting, controls over expression and escape interpretation, as well as inline HEREDOCs defined with optional leading whitespace elimination and END DATA blocks.
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
In-depth study.
···
On Apr 6, 2017, at 1:35 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
More information about the Swift evolution process is available at:
First of all, to be clear: although my name is on this proposal, it's there because I worked on it last year when we were exploring other approaches. I haven't worked on this version of the proposal and wasn't aware that it was up for review until the announcement went out. So the below is just my opinion; it does not represent the opinion of the other authors, and I haven't even talked to them about it. So don't take this as "even the authors aren't totally happy with this proposal". :^)
• What is your evaluation of the proposal?
I think that, if we want to do something in the style of Python's multiline string literals, this proposal specifies a good design for them. It addresses one of the main problems with them in Python—the fact that they typically have to be flush against the left margin—and, although we might want to tighten the description of the de-indenting algorithm, I think its proposal in this area is basically the right thing to do. Others have argued that we should use a #keyword or special syntax for this, but I don't think that's the right move; we should always have de-indenting on, because you usually want it, and when you don't, you can easily "turn it off" by positioning the delimiter so it infers zero indentation.
Specifically, here are the rules I would specify for indentation:
— If the leading delimiter is at the end of its line, *and* the characters between the trailing delimiter and the newline before it consist entirely of zero or more horizontal whitespace characters, the literal uses de-indenting.
—If one of these conditions is true but not the other, we may want to emit a warning.
— If a literal uses de-indenting:
1. The one newline after the leading delimiter is removed.
2. The whitespace on the last line is removed.
3. Each line is compared to the whitespace removed from the last line. The largest common prefix of characters that are exact matches for the whitespace removed from the last line are removed.
— If we only matched a prefix of the last line's whitespace, but not all of it, we should emit a warning—*especially* if the non-matching character was a whitespace character, but not the one we expected.
So, for instance, this code (⎵ = space, ⇥ = tab, ↵ = newline):
"""↵
⎵⎵⎵⎵Foo↵
⎵⎵⇥Bar↵
⎵⎵⎵⎵"""
Creates a literal with these contents (and probably a warning on the "Bar" line):
Foo↵
⇥Bar↵
However, this code (with non-whitespace before the trailing `"""`):
"""↵
⎵⎵⎵⎵Foo↵
⎵⎵⇥Bar"""
Would be:
↵
⎵⎵⎵⎵Foo↵
⎵⎵⇥Bar
And this code (with no newline after the leading `"""`) :
"""⎵⎵⎵⎵Foo↵
⎵⎵⇥Bar↵
⎵⎵⎵⎵"""
Would be:
⎵⎵⎵⎵Foo↵
⎵⎵⇥Bar↵
⎵⎵⎵⎵
Finally, if you escape a newline, the newline should not be included in the string, but de-indenting should still happen. So this string:
"""↵
⎵⎵⎵⎵Foo\↵
⎵⎵⇥Bar\↵
⎵⎵⎵⎵"""
Becomes this (plus a warning for the mismatched indentation):
Foo↦Bar
* * *
However, I'm not sure Python-style quoting is our best alternative. But that's very much a matter of opinion, because there's no knockout winner in this area.
Basically, every multiline string literal design I'm aware of has at least two of these three weaknesses:
1. It doesn't help you with strings which themselves contain quote marks (and, thus, you have to backslash them).
2. There's little redundancy in the syntax, which makes parsing difficult, particularly when code is incomplete or out of context. Basically, at any point in the code, you might be in a multiline string literal or you might be in actual code, and the only way to know which is to look at the entire file before that point. And that assumes the code is well-formed. If someone forgets—or hasn't yet typed—a closing `"""`, you can tell that one of the multiline strings in the file is unclosed, but it's not clear which one. You end up applying a heuristic: It's *probably* the one before where you start getting syntax errors from the "code" you're parsing. But that heuristic can be wrong, particularly if you have Swift code that's generating Swift code.
3. Conventional string literal syntax has you place the full content of the string in the place where it will go in the expression. That's fine for short strings, but when you start looking at long multiline strings, all that extra content makes the expression difficult to read. It's like having a hundred-word parenthetical in the middle of a sentence: By the time it's finished, you've forgotten where the outer sentence left off.
(The naïve multi-line string literal approach—"we'll just allow newlines in a normal string literal"—suffers from all three of these problems.)
Python-style quoting avoids #1, but has to deal with #2 and #3. That's clever in that it means one syntax plays two roles, but it's really easy to add #1 as a separate feature (like by making `'` an alternate delimiter, or adding a feature like Perl's `qq` which lets you choose any character as a delimiter), whereas #2 and #3 can't be fixed by simply adding another feature.
A design that addresses #2, while leaving #1 and #3 on the table, is continuation quotes. Basically, if a normal, one-double-quote-mark-delimited string literal is not terminated before the end of a line, the compiler looks at the next line. If the next line starts with optional whitespace followed by the opening string literal delimiter, then the string continues onto that line. Because every line of the string literal affirms that the string literal is meant to continue onto this line, mistakes are diagnosed very close to where the user made them. Syntax highlighting also doesn't require full knowledge of the file; a relatively naïve highlighter, like the ones common in text editors and CMSes, can consider each line in isolation and still apply correct highlighting to code. The main problem with this approach is that it doesn't allow you to paste text in verbatim—you must modify each line to add a leading quote mark—but I think editor support can address that shortcoming. It also still requires you to escape double-quotes in the text, but as I said, that can be addressed through a separate feature.
A design that addresses #3, while leaving #1 (partially) and #2 on the table, is heredocs. In a heredoc, the expression contains a token indicating the presence of a multiline string, but the contents of the string don't actually start immediately. Instead, the contents begin on the next line. The token merely primes the parser to look for a multiline string and indicates where in the expression it belongs. This means the expression is easy to read and the string is slightly out-of-band. There's also a second advantage to heredocs: Although they don't help you with *single-line* strings that contain `"`, they do help you with *multi-line* strings that do. Traditionally, the heredoc token is `<<` followed by an arbitrary delimiter, but I actually really like the `"""` token from Python, so personally I would steal that and use it as both the token and the delimiter:
assert( xml == """ )
<?xml version="1.0"?>
<catalog>
<book id="bk101" empty="">
<author>\(author)</author>
<title>XML Developer's Guide</title>
<genre>Computer</genre>
<price>44.95</price>
<publish_date>2000-10-01</publish_date>
<description>An in-depth look at creating applications with XML.</description>
</book>
</catalog>
"""
Although this idea has not been fully fleshed out, I've also considered a sort-of-heredoc-ish syntax involving functions. Basically, by annotating a function or method with an attribute like `@quoted` (or, alternately, by using `"""` instead of `{` to open the body), you would change the interpretation of its body: it would be treated as the contents of a giant, interpolatable string literal instead of as Swift code. This encourages you to explicitly name and parameterize your long string literals, allows you to move them around in your source code (possibly even to separate files), and permits you to refactor them into code if that makes sense. But it also starts to look not so much like string literals anymore.
My point is this: There are a lot of plausible designs in this space, and they all have different trade-offs. Pros of the Python-style syntax in this proposal:
1. It's easy to explain.
2. It does double duty by also quoting short strings with double-quote marks in them.
3. It doesn't require you to modify the contents of the literal.
Cons:
1. Incomplete or incorrect code is very ambiguous, so diagnosing errors or highlighting code being written is imprecise and heuristic-driven.
2. It takes more work to syntax highlight even when code is correct.
3. It breaks up expressions, making them less readable.
4. The amount of de-indenting is determined by implication (vs. continuation quotes, where the ignored whitespace is explicit).
It might look bad when I write it like that, but the reality is that all possible syntaxes have similarly mixed trade-offs.
The core team may feel that, given Swift's goals, Python-style multiline string syntax is the right choice—it kills two birds with one stone and is easy to teach, so tool designers will just have to deal with the challenges it poses, and people will need to adopt styles where they're not used in long expressions. But when the core team deliberates, I hope they will discuss and weigh these trade-offs explicitly. If they do choose to reject, I hope they communicate their priorities to us so we can write a proposal that matches them. But if they feel this type of string literal syntax meets their goals for multiline string literals, I urge them to accept this proposal.
• Is the problem being addressed significant enough to warrant a change to Swift?
Yes. The current need to heavily escape string literals—and especially multiline ones—makes code that works with strings difficult to read and unpleasant to write. A new feature is sorely needed in this area.
• Does this proposal fit well with the feel and direction of Swift?
There is definitely something lightweight and parsimonious about the Python design; that feels a bit Swifty.
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I've spent a lot of my career in dynamic languages with good string-handling facilities, including strong string literal syntax features. A brief survey of the languages in this category:
* Perl 5 has highly-configurable quoting facilities permitting arbitrary delimiters, plus heredocs. It does not have deindenting, though.
* Perl 6 has everything Perl 5 does, plus de-indenting and the ability to write your own quoting mechanisms.
* Ruby also has Perl 5-like quoting facilities, plus deindenting.
* Python has a syntax that directly inspired this one.
To explain in a little more detail, Perl 5 and Ruby have several different interlocking quote features:
1. A string delimited by double quotes supports backslash escapes and interpolation; a string delimited by single quotes does not.
2. There are special tokens which are equivalent to single- and double-quoted strings. (`q` and `qq` in Perl; `%q` and `%Q` in Ruby.) After the token, the next non-whitespace, non-identifier character (sort of) becomes a delimiter; when it is repeated un-backslashed, the string literal ends. As a special exception,starting delimiters like `<`, `[`, `(` and `{` are terminated by their matching closing character, and non-backslashed inner instances of these characters are counted and balanced.
3. They also support heredocs. In these languages, a heredoc token is a `<<` character followed by a short string in any of the other literal syntaxes; the contents of that literal are the delimiter for the heredoc, while the quoting style used on the literal controls the quoting style of the heredoc. (Ruby also uses certain prefix characters on the delimiter to describe various whitespace-stripping behaviors.
4. You can put any character, including newlines, in any of these string literal types.
Perl 6 refactors these features a bit by rebuilding them around a modifier system on the `q` and `qq` operators; for instance, `q:b(zyz\nyx)` uses single-quote semantics except that it interprets backslash escapes, while `qq:to(END)` creates a double-quote-style heredoc delimited by `END`.
Python, on the other hand, has a much simpler set of features:
1. There are two single-line string delimiters: `'` and `"`. They have identical semantics; you just choose one based on style or the literal's contents. Newlines are not allowed in these strings, unless they're escaped with a backslash (in which case they're ignored).
2. There are two multi-line string delimiters: `'''` and `"""`. Again, they have identical semantics. Newlines *are* allowed in these strings.
3. An `r` or `R` prefix on the string literal disables processing of backslash escapes. (Well, sort of—a backslash still prevents a quote mark after it from ending the string, but the backslash itself is also left in.)
Note that these rules *are* different from the ones proposed for Swift: Python includes every character between the multi-line string delimiters in the string, whereas we are removing indentation and a leading newline.
In my experience, I much prefer the Perl-style model with several different orthogonal features to the Python style with a couple of minimal features. The Python-style quotes are usually acceptable but almost never ideal, whereas in the Perl/Ruby style, one tool or another always feels like a perfect fit. But I also have *much* more experience with the Perl style, so that might just be what I'm used to. And Perl is a language specifically built for string handling, while Swift is not; it may not make sense to devote anywhere near as much syntactic attention to string literals.
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Well, I might not have been involved with it the whole time through, but my name *is* on the proposal, right?
···
On Apr 6, 2017, at 12:35 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
–1 for the proposed solution, but in general I’d myself would want to see multi-line strings in Swift. The current proposal does not cover precision, which could also be desired by developers.
My _personal_ view on how I wish multi-line strings do behave is actually similar to the magical string concatenation which is an optimization during compile time (not included in Xcode 8.3). Many people disagree with this point of view in favor of implicit new lines and non escaped " character, which is fine by me only if we can extend the standard string literal to support multilines too. Such extension will be stricter and have special precision rules.
// Simplicity which supports indent but at a cost of no
// leading or trailing space characters
let string1 = "my
multiline
string"
print(string1) // prints "mymultilinestring"
let string2 = "my \
multiline \
string"
// Trailing precision
print(string2) // prints "my multiline string"
let string3 = "my
" multiline
" string"
// Leading precision
print(string3) // prints "my multiline string"
let string4 = "my \
" multiline \
" string"
// Leading and trailing precision
print(string4) // prints "my multiline string" (Note: 2x two whitespaces)
let string5 = "my\
"multiline\
"string"
// Leading and trailing precision
// Provide a fix-it to remove some `\` and `"` characters
// because it equals `string1`
print(string5) // prints "mymultilinestring"
let string6 = "my \
"multiline \
"string"
// Leading and trailing precision
// Provide a fix-it to remove some `"` characters
// because it equals `string2`
print(string6) // prints "my multiline string"
let string7 = "my\
" multiline\
" string"
// Leading and trailing precision
// Provide a fix-it to remove some `\` characters
// because it equals `string3`
print(string7) // prints "my multiline string"
Additionally you can support a similar version of multilines strings with """ notation for those of use who are lazy to type \n and \" and want implicit new lines. However this raises the question, if the addition of """ is warrant it’s existence only for laziness and copy pasting?
The above example should also support string interpolation.
Is the problem being addressed significant enough to warrant a change to Swift?
Not enough from my point of view.
Does this proposal fit well with the feel and direction of Swift?
The addition of multi-lined strings does fit, however I don’t think the proposed solution satisfies everyone. Personally I’d probably never use a multi-lined string as proposed, just because it adds implicit new lines to my very long string, which I maybe only want to break up into a few lines for better readability without the boilerplate of the not so obvious optimization magic provided by the complier though the concatenation operator +.
I think the correct name is *multi line string literal*, which is different from _multi line string_. The former should not have any implicit behavior except if there are two different versions like "__" and """___""".
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Javascript has this nice ability to break up strings into multilines with trailing precision, which I used in the example above.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Read the whole proposal and took part in latest discussion thread.
···
--
Adrian Zubarev
Sent with Airmail
Am 6. April 2017 um 21:35:50, Joe Groff via swift-evolution (swift-evolution@swift.org) schrieb:
Hello Swift community,
The review of SE-0168 "Multi-Line String Literals" begins now and runs through April 12, 2017. The proposal is available here:
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
Proposal link:
Reply text
Other replies
What goes into a review?
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?
More information about the Swift evolution process is available at:
My foremost expectation from multiline string literals is to be able to copy and paste multiline string literals without having to fiddle with escape marks or leading and trailing quotes or continuation characters. This is exactly what the proposal provides and makes it easy to embed SQL, for example (using SQL parameters and not string interpolation of course ;-)
The chosen deindentation rules seem very pragmatic and useful to me.
Additional features for multiline string literals can be added easily later.
I would expect multiline string literals to use the same newline character as "\n“ does, regardless of the newline character actually used in the file.
Furthermore all normal escapes, e.g. \n, \t etc. should probably be available as well.
This should be stated explicitly in the proposal.
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?
Yes.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
For setting the ground it compares favourably.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Yes good idea. Though I am not clear as to whether the final return before the closing """ is included in the literal or not. If not, would a blank line before """ enclose a return at the end. If yes, would the closing """ have to be on the same line to prevent a return at the end. It doesn't really matter which option, but it wasn't clear to me what happens.
• Is the problem being addressed significant enough to warrant a change to Swift?
Yes. Very handy on server side code.
• Does this proposal fit well with the feel and direction of Swift?
Yes, with the push onto server side it is a nice addition.
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Yes. Lots of languages have similar.
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Quick read.
-- Howard.
···
On 7 Apr 2017, at 5:35 am, Joe Groff <jgroff@apple.com> wrote:
review of SE-0168 "Multi-Line String Literals" begins now and runs through April 12, 2017. The proposal is available here:
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
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?
