[Review] SE-0182 - String Newline Escaping

Evolution Announcements
1

Hello Swift community,

Context: As part of winding down work on Swift 4, we are considering SE-0182 as a refinement to SE-0168. We are specifically not opening the floodgates for new proposals just yet, and it is not considered in scope to resyntax all of multi-line string literals. We’re just discussing this one potential small-scope refinement to an existing Swift 4 feature.

The review of "String Newline Escaping" begins now and runs through July 17, 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:

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:

Thank you,

Chris Lattner
Review Manager

2

+1 This seems great to me. It seems worth calling out how escaping of backslashes and escaping of newlines interact for testing:

  let s = """
  line fragment ending in backslash \\\
        and
  line fragment ending in backslash \\\
        \\followed by line fragment starting with backslash
  """

I would expect to get "line fragment ending in backslash \\and\nline fragment ending in backslash\\\\followed by line fragment starting with backslash”, that is, escaped backslashes at the end of line fragments should be retained, and whatever concatenates line fragments shouldn’t accidentally double-interpret backslashes.

Alternatively:

  let s = """
  line ending in backslash \\
        and
  line ending in backslash \\
        \\followed by line starting with backslash
  """

seems like it should produce the result "line ending in backslash \\\nand\nline ending in backslash\\\n\\followed by line starting with backslash”, that is, the consumption of escaped backslashes should happen before considering if there is an extra backslash on the end of the line for an escaped newline.

-tim

···

On Jul 12, 2017, at 3:52 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

Context: As part of winding down work on Swift 4, we are considering SE-0182 as a refinement to SE-0168. We are specifically not opening the floodgates for new proposals just yet, and it is not considered in scope to resyntax all of multi-line string literals. We’re just discussing this one potential small-scope refinement to an existing Swift 4 feature.

The review of "String Newline Escaping" begins now and runs through July 17, 2017. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md

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:

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:
https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Chris Lattner
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

Yes please! +1
  While I’d like simpler string literal syntax, this would fix one of the last remaining pain points.

Jon

···

On Jul 12, 2017, at 6:52 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

Context: As part of winding down work on Swift 4, we are considering SE-0182 as a refinement to SE-0168. We are specifically not opening the floodgates for new proposals just yet, and it is not considered in scope to resyntax all of multi-line string literals. We’re just discussing this one potential small-scope refinement to an existing Swift 4 feature.

The review of "String Newline Escaping" begins now and runs through July 17, 2017. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md

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:

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:
https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Chris Lattner
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

The review of "String Newline Escaping" begins now and runs through July
17, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md

        • What is your evaluation of the proposal?

+1. Useful addition to multi-strings and correct decision for single line.

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

Yes is an issue for multi line strings

        • 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?

Yes, very handy

        • How much effort did you put into your review? A glance, a quick
reading, or an in-depth studyOn Thu, 13 Jul 2017 at 8:52 am, Chris Lattner <

Hello Swift community,

Quick read of proposal

Context: As part of winding down work on Swift 4, we are considering
SE-0182 as a refinement to SE-0168. We are specifically not opening the
floodgates for new proposals just yet, and it is not considered in scope to
resyntax all of multi-line string literals. We’re just discussing this one
potential small-scope refinement to an existing Swift 4 feature.

?

···

clattner@nondot.org> wrote:

More information about the Swift evolution process is available at:
https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Chris Lattner
Review Manager
_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

--
-- Howard.

5

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md\]

This is a tiny, tiny point amidst the broader discussions others are having, but

  • All whitespace characters between \ and the newline are disregarded.

Why? Why bother allowing whitespace characters between \ and the newline?

Thanks,
Jordan

6

Hello Swift community,

Context: As part of winding down work on Swift 4, we are considering
SE-0182 as a refinement to SE-0168. We are specifically not opening the
floodgates for new proposals just yet, and it is not considered in scope to
resyntax all of multi-line string literals. We’re just discussing this one
potential small-scope refinement to an existing Swift 4 feature.

The review of "String Newline Escaping" begins now and runs through July
17, 2017. The proposal is available here:
GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
proposals/0182-newline-escape-in-strings.md

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:

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?

I agree with Adrian's appraisal of this proposal. Namely, if the core team
believes that now is the right time to evaluate new additions to multiline
string literal syntax, the addition of `\` as a way to escape the newline
is straightforward and has its benefits. However, as voiced by several
others, the proposal to add the same feature to single-line string literals
should be reconsidered. The specific objections I have in mind, I will
detail under the following sections.

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

Potentially. On this point I'm not fully convinced as to how significant
the problem is. However, the proposed solution is an additive change that
is fairly "obvious" and unlikely to be problematic.

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

As to multiline string literal syntax, yes. However, I'll outline here my
thinking on the issue with single-line string literals.

The core team rejected this particular feature in the previous proposal for
multiline string literals with the admonition that any later addition
should address both single-line and multiline string literals. The authors
appear to have taken this literally by simply proposing the same feature
for both. In previous conversations, it has become apparent that many other
possible designs for escaping newlines in both single-line and multiline
string literals turn out to be clunky for one or for the other (or for
both); _none_ have emerged that seem to work equally well in both
situations. Therefore, it is unsurprising that the authors of the current
proposal simply propose to use the backslash syntax for both.

I'll rationalize my unease with this solution in the following manner:

1. Generally, `\` is used to escape some other sequence of characters. By
that, I mean that the sequence of characters means one thing without the
preceding `\` and another with `\`.
2. In multiline string literals, a naked newline means a newline in the
represented string; therefore, it makes good sense that `\` + newline is
used to insert a newline in the literal but not in the resulting string.
3. In single-line string literals, a naked newline is illegal. Hence, `\` +
newline is "escaping" a sequence of characters that by itself isn't even
permitted in the literal.

This results in an asymmetry that is rather odd. In my view, there's one of
two ways to resolve this problem:

1. Do not add the proposed feature to single-line string literals (Adrian
proposes this resolution as well). The basis for such a discrepancy would
be: single-line string literals don't allow newlines; that's what makes
them single-line string literals. The preferred spelling for a single line
string represented over multiple lines using single-line string literal
syntax would remain:

let foo = "Hello, "
          + "world!"

OR

2. Do add the proposed feature to single-line string literals. In addition,
do add the possibility of using a naked newline character to denote a
newline in the resulting string. That is, allow both:

let foo = "Hello, \
world!"

// Hello, world!

let bar = "Hello,
world!"

// Hello,
// world!

To my mind, whether (1) or (2) is preferable depends on whether the Swift
community believes that the predominant distinction is between string
literals that happen to span a single line vs. multiple lines in code
(i.e., single-line (string literal) vs. multiline (string literal)) or
between literals that represent a single-line string (modulo escaped
newline sequences) vs. those that represent multiline strings (i.e.,
(single-line string) literal vs. (multiline string) literal).

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

JavaScript template literals do have a similar feature. In that language
(unless I'm mistaken), the same does not apply to ordinary strings.
In Python, `\` can be used for line continuations; this is the case both
inside strings and outside strings.
C and Python allow adjacent string literals to be concatenated, which is
straightforward and a valid alternative for consideration here.

        • How much effort did you put into your review? A glance, a quick

reading, or an in-depth study?

A quick reading; previously, an in-depth study of the original proposal.

···

On Wed, Jul 12, 2017 at 5:52 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

More information about the Swift evolution process is available at:
https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Chris Lattner
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

7

+1

Maintaining parity between single and multi line strings is nice even
though breaking scope is a strong argument against actually using this with
single line literals.

···

On Wed, Jul 12, 2017 at 7:15 PM, Timothy Wood via swift-evolution < swift-evolution@swift.org> wrote:

+1 This seems great to me. It seems worth calling out how escaping of
backslashes and escaping of newlines interact for testing:

        let s = """
        line fragment ending in backslash \\\
        and
        line fragment ending in backslash \\\
        \\followed by line fragment starting with backslash
        """

I would expect to get "line fragment ending in backslash \\and\nline
fragment ending in backslash\\\\followed by line fragment starting with
backslash”, that is, escaped backslashes at the end of line fragments
should be retained, and whatever concatenates line fragments shouldn’t
accidentally double-interpret backslashes.

Alternatively:

        let s = """
        line ending in backslash \\
        and
        line ending in backslash \\
        \\followed by line starting with backslash
        """

seems like it should produce the result "line ending in backslash
\\\nand\nline ending in backslash\\\n\\followed by line starting with
backslash”, that is, the consumption of escaped backslashes should happen
before considering if there is an extra backslash on the end of the line
for an escaped newline.

-tim

> On Jul 12, 2017, at 3:52 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Hello Swift community,
>
> Context: As part of winding down work on Swift 4, we are considering
SE-0182 as a refinement to SE-0168. We are specifically not opening the
floodgates for new proposals just yet, and it is not considered in scope to
resyntax all of multi-line string literals. We’re just discussing this one
potential small-scope refinement to an existing Swift 4 feature.
>
>
> The review of "String Newline Escaping" begins now and runs through July
17, 2017. The proposal is available here:
> GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
proposals/0182-newline-escape-in-strings.md
>
> 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:
>
> 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:
> https://github.com/apple/swift-evolution/blob/master/process.md
>
>
> Thank you,
>
> Chris Lattner
> Review Manager
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

8

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md\]

This is a tiny, tiny point amidst the broader discussions others are having, but

  • All whitespace characters between \ and the newline are disregarded.

Why? Why bother allowing whitespace characters between \ and the newline?

The reasoning is to be consistent with trailing whitespace in the rest of the code: to leave that to a linter instead. Or to see it differently, even with whitespace between \ and the newline, the programmer’s intent is still clear. Why generate an error?

David.

···

On 14 Jul 2017, at 00:21, Jordan Rose <jordan_rose@apple.com> wrote:

Thanks,
Jordan

9

as is, this will mess up the “collapse” feature in most text editors,, it
should not be added unless indentation removal is added too

···

On Wed, Jul 12, 2017 at 7:48 PM, T.J. Usiyan via swift-evolution < swift-evolution@swift.org> wrote:

+1

Maintaining parity between single and multi line strings is nice even
though breaking scope is a strong argument against actually using this with
single line literals.

On Wed, Jul 12, 2017 at 7:15 PM, Timothy Wood via swift-evolution < > swift-evolution@swift.org> wrote:

+1 This seems great to me. It seems worth calling out how escaping of
backslashes and escaping of newlines interact for testing:

        let s = """
        line fragment ending in backslash \\\
        and
        line fragment ending in backslash \\\
        \\followed by line fragment starting with backslash
        """

I would expect to get "line fragment ending in backslash \\and\nline
fragment ending in backslash\\\\followed by line fragment starting with
backslash”, that is, escaped backslashes at the end of line fragments
should be retained, and whatever concatenates line fragments shouldn’t
accidentally double-interpret backslashes.

Alternatively:

        let s = """
        line ending in backslash \\
        and
        line ending in backslash \\
        \\followed by line starting with backslash
        """

seems like it should produce the result "line ending in backslash
\\\nand\nline ending in backslash\\\n\\followed by line starting with
backslash”, that is, the consumption of escaped backslashes should happen
before considering if there is an extra backslash on the end of the line
for an escaped newline.

-tim

> On Jul 12, 2017, at 3:52 PM, Chris Lattner via swift-evolution < >> swift-evolution@swift.org> wrote:
>
> Hello Swift community,
>
> Context: As part of winding down work on Swift 4, we are considering
SE-0182 as a refinement to SE-0168. We are specifically not opening the
floodgates for new proposals just yet, and it is not considered in scope to
resyntax all of multi-line string literals. We’re just discussing this one
potential small-scope refinement to an existing Swift 4 feature.
>
>
> The review of "String Newline Escaping" begins now and runs through
July 17, 2017. The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/proposa
ls/0182-newline-escape-in-strings.md
>
> 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:
>
> 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:
> https://github.com/apple/swift-evolution/blob/master/process.md
>
>
> Thank you,
>
> Chris Lattner
> Review Manager
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

10

For the same reason that code allows (e.g.) a comment at the end of the line; you wouldn't expect (newline continuation) (comment) to mean the same thing as if generic whitespace were added at the end. The convention in other languages is that \ immediately precedes the line feed to indicate a continuation, not that an orphan \ is valid on its own.

The reason that \(newline) is valid while \(otherchar)(newline) isn't is because \ immediately precedes another character that it is escaping, and it's possible that \(space) would have a meaning in the future, whereas \(newline) won't.

Alex

···

On 13 Jul 2017, at 23:14, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

On 14 Jul 2017, at 00:21, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md\]

This is a tiny, tiny point amidst the broader discussions others are having, but

  • All whitespace characters between \ and the newline are disregarded.

Why? Why bother allowing whitespace characters between \ and the newline?

The reasoning is to be consistent with trailing whitespace in the rest of the code: to leave that to a linter instead. Or to see it differently, even with whitespace between \ and the newline, the programmer’s intent is still clear. Why generate an error?

11

Can you please elaborate?

···

—

In general I, as one of the co-authors, am for this additional change. However, personally I would be against adding the new line escaping feature to the single double-quote string literal, because it will create asymmetry.

For instance in a future proposal it’s likely we’d also allow the multi-line string literal """ to be written in a single line without any new line escaping, for strings that contain lots of double-quotes:

let myString1 = """{"id": "OpenNew", "label": "Open New"}"""

// old and current version
let myString2 = "{\"id\": \"OpenNew\", \"label\": \"Open New\"}"
Considering that proposal would be accepted we’d have two ways to express the multi-line string literal:

// horizontal
"""Swift"""

// vertical
"""
Swift
"""
Now about the previously mentioned asymmetry, if we’d accept in the current proposal and include new line escaping in a single double-quoted string literal eventually someone will find that again inconsistent and ask to align """-literal to allow:

"""abc \
def"""
    
// Symmetrical counterpart is from the current proposal
"abc \
def"
However this model was completely abandoned by the previous proposal and should be avoided at all cost even in the future, because it does not any value to the expressiveness, but only complicates the model.

—

On the other hand if we’re really considering adding this to "-literal, then it should be only possible if the "-literal gets a similar vertical version like the """-literal.

Notice that in that scenario:

we need borrow the indent mechanism from """
the trailing \ can be omitted after the last character on the current string line
the trailing \ is only used for annotate trailing whitespaces ("-liteal does not add implicit new lines at all, it’s always should stay explicit about everything)
Something like that:

// #1
"
a\
b\
" == "ab"

// #1.1
"
a
b
" == "ab"

// #2
"
a \
b \
" == "a b "

// #3
"
c \
d \
" == " c d "
By now it should be clearly visible that this extension for the "-literal does not add anything what the """-literal cannot already solve nicely!

That said, let’s keep it simple and only add the \ to vertical """-literal.

--
Adrian Zubarev
Sent with Airmail

On 13. July 2017 at 02:10:30, Taylor Swift via swift-evolution (swift-evolution@swift.org) wrote:

as is, this will mess up the “collapse” feature in most text editors,, it should not be added unless indentation removal is added too

On Wed, Jul 12, 2017 at 7:48 PM, T.J. Usiyan via swift-evolution <swift-evolution@swift.org> wrote:
+1

Maintaining parity between single and multi line strings is nice even though breaking scope is a strong argument against actually using this with single line literals.

On Wed, Jul 12, 2017 at 7:15 PM, Timothy Wood via swift-evolution <swift-evolution@swift.org> wrote:

+1 This seems great to me. It seems worth calling out how escaping of backslashes and escaping of newlines interact for testing:

    let s = &quot;&quot;&quot;
    line fragment ending in backslash \\\\\\
    and
    line fragment ending in backslash \\\\\\
    \\\\followed by line fragment starting with backslash
    &quot;&quot;&quot;

I would expect to get "line fragment ending in backslash \\and\nline fragment ending in backslash\\\\followed by line fragment starting with backslash”, that is, escaped backslashes at the end of line fragments should be retained, and whatever concatenates line fragments shouldn’t accidentally double-interpret backslashes.

Alternatively:

    let s = &quot;&quot;&quot;
    line ending in backslash \\\\
    and
    line ending in backslash \\\\
    \\\\followed by line starting with backslash
    &quot;&quot;&quot;

seems like it should produce the result "line ending in backslash \\\nand\nline ending in backslash\\\n\\followed by line starting with backslash”, that is, the consumption of escaped backslashes should happen before considering if there is an extra backslash on the end of the line for an escaped newline.

-tim

On Jul 12, 2017, at 3:52 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

Context: As part of winding down work on Swift 4, we are considering SE-0182 as a refinement to SE-0168. We are specifically not opening the floodgates for new proposals just yet, and it is not considered in scope to resyntax all of multi-line string literals. We’re just discussing this one potential small-scope refinement to an existing Swift 4 feature.

The review of "String Newline Escaping" begins now and runs through July 17, 2017. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md

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:

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:
https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Chris Lattner
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

12

I agree with Alex on this, although I would be happy to make it a warning rather than an error so that it doesn't block compilation.

The point about comments is also significant: we previously said that comments should generally be treated like whitespace (SE-0037 <https://github.com/apple/swift-evolution/blob/master/proposals/0037-clarify-comments-and-operators.md&gt;\). This is a little different because it's still inside the string literal, but it's probably worth explicitly stating "we're still inside a string literal; you can't just put comments after the backslash".

Jordan

···

On Jul 14, 2017, at 10:00, Alex Blewitt <alblue@apple.com> wrote:

On 13 Jul 2017, at 23:14, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 14 Jul 2017, at 00:21, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md\]

This is a tiny, tiny point amidst the broader discussions others are having, but

  • All whitespace characters between \ and the newline are disregarded.

Why? Why bother allowing whitespace characters between \ and the newline?

The reasoning is to be consistent with trailing whitespace in the rest of the code: to leave that to a linter instead. Or to see it differently, even with whitespace between \ and the newline, the programmer’s intent is still clear. Why generate an error?

For the same reason that code allows (e.g.) a comment at the end of the line; you wouldn't expect (newline continuation) (comment) to mean the same thing as if generic whitespace were added at the end. The convention in other languages is that \ immediately precedes the line feed to indicate a continuation, not that an orphan \ is valid on its own.

The reason that \(newline) is valid while \(otherchar)(newline) isn't is because \ immediately precedes another character that it is escaping, and it's possible that \(space) would have a meaning in the future, whereas \(newline) won't.

13

One more thing I wanted to add.

I would remove the restriction of

An escape character at the end of the last line of a literal is an error, as no newlines follow.
from this proposal and allow the trailing backslash in the last line which won’t do harm to anything. The idea behind this is that one could annotate whitespaces in the last line:

"""
My very long string<space>\
in Swift :ghost:<space><space><space>\
"""

···

--
Adrian Zubarev
Sent with Airmail

On 13. July 2017 at 08:14:03, Adrian Zubarev (adrian.zubarev@devandartist.com) wrote:

Can you please elaborate?

—

In general I, as one of the co-authors, am for this additional change. However, personally I would be against adding the new line escaping feature to the single double-quote string literal, because it will create asymmetry.

For instance in a future proposal it’s likely we’d also allow the multi-line string literal """ to be written in a single line without any new line escaping, for strings that contain lots of double-quotes:

let myString1 = """{"id": "OpenNew", "label": "Open New"}"""

// old and current version
let myString2 = "{\"id\": \"OpenNew\", \"label\": \"Open New\"}"
Considering that proposal would be accepted we’d have two ways to express the multi-line string literal:

// horizontal
"""Swift"""

// vertical
"""
Swift
"""
Now about the previously mentioned asymmetry, if we’d accept in the current proposal and include new line escaping in a single double-quoted string literal eventually someone will find that again inconsistent and ask to align """-literal to allow:

"""abc \
def"""
     
// Symmetrical counterpart is from the current proposal
"abc \
def"
However this model was completely abandoned by the previous proposal and should be avoided at all cost even in the future, because it does not any value to the expressiveness, but only complicates the model.

—

On the other hand if we’re really considering adding this to "-literal, then it should be only possible if the "-literal gets a similar vertical version like the """-literal.

Notice that in that scenario:

we need borrow the indent mechanism from """
the trailing \ can be omitted after the last character on the current string line
the trailing \ is only used for annotate trailing whitespaces ("-liteal does not add implicit new lines at all, it’s always should stay explicit about everything)
Something like that:

// #1
"
a\
b\
" == "ab"

// #1.1
"
a
b
" == "ab"

// #2
"
a \
b \
" == "a b "

// #3
"
c \
d \
" == " c d "
By now it should be clearly visible that this extension for the "-literal does not add anything what the """-literal cannot already solve nicely!

That said, let’s keep it simple and only add the \ to vertical """-literal.

--
Adrian Zubarev
Sent with Airmail

On 13. July 2017 at 02:10:30, Taylor Swift via swift-evolution (swift-evolution@swift.org) wrote:

as is, this will mess up the “collapse” feature in most text editors,, it should not be added unless indentation removal is added too

On Wed, Jul 12, 2017 at 7:48 PM, T.J. Usiyan via swift-evolution <swift-evolution@swift.org> wrote:
+1

Maintaining parity between single and multi line strings is nice even though breaking scope is a strong argument against actually using this with single line literals.

On Wed, Jul 12, 2017 at 7:15 PM, Timothy Wood via swift-evolution <swift-evolution@swift.org> wrote:

+1 This seems great to me. It seems worth calling out how escaping of backslashes and escaping of newlines interact for testing:

    let s = &quot;&quot;&quot;
    line fragment ending in backslash \\\\\\
    and
    line fragment ending in backslash \\\\\\
    \\\\followed by line fragment starting with backslash
    &quot;&quot;&quot;

I would expect to get "line fragment ending in backslash \\and\nline fragment ending in backslash\\\\followed by line fragment starting with backslash”, that is, escaped backslashes at the end of line fragments should be retained, and whatever concatenates line fragments shouldn’t accidentally double-interpret backslashes.

Alternatively:

    let s = &quot;&quot;&quot;
    line ending in backslash \\\\
    and
    line ending in backslash \\\\
    \\\\followed by line starting with backslash
    &quot;&quot;&quot;

seems like it should produce the result "line ending in backslash \\\nand\nline ending in backslash\\\n\\followed by line starting with backslash”, that is, the consumption of escaped backslashes should happen before considering if there is an extra backslash on the end of the line for an escaped newline.

-tim

On Jul 12, 2017, at 3:52 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

Context: As part of winding down work on Swift 4, we are considering SE-0182 as a refinement to SE-0168. We are specifically not opening the floodgates for new proposals just yet, and it is not considered in scope to resyntax all of multi-line string literals. We’re just discussing this one potential small-scope refinement to an existing Swift 4 feature.

The review of "String Newline Escaping" begins now and runs through July 17, 2017. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md

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:

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:
https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Chris Lattner
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

14

As this review winds down it seems fair to say the response has been generally
favourable with some reservations about whether this should be applied to single
line strings as well. I’d include single line strings myself for consistency with multi-
line and with other languages myself but that isn’t the focus of this proposal.

There has also been some discussion about whether escaping the last newline should
be an error or ignored. For me this highlights that the final newline should be included
in the literal and could therefore be escaped when you want one without a newline at
the end which may or may not be the common use case as has been discussed before.

let text = """
    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod \
    tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, \
    quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.\
    """

let endsWithNewline = """
    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
    tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
    quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
    """

While multi-line strings would loose their pleasing symmetry from SE-0168 where initial
and final newlines are stripped I'd argue in response that text is generally asymmetric
with files generally having no newline at the start and a newline at the end. I can see
the arguments for both decisions though and could live with either.

-John

···

On 14 Jul 2017, at 18:17, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

On Jul 14, 2017, at 10:00, Alex Blewitt <alblue@apple.com <mailto:alblue@apple.com>> wrote:

On 13 Jul 2017, at 23:14, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 14 Jul 2017, at 00:21, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md\]

This is a tiny, tiny point amidst the broader discussions others are having, but

  • All whitespace characters between \ and the newline are disregarded.

Why? Why bother allowing whitespace characters between \ and the newline?

The reasoning is to be consistent with trailing whitespace in the rest of the code: to leave that to a linter instead. Or to see it differently, even with whitespace between \ and the newline, the programmer’s intent is still clear. Why generate an error?

For the same reason that code allows (e.g.) a comment at the end of the line; you wouldn't expect (newline continuation) (comment) to mean the same thing as if generic whitespace were added at the end. The convention in other languages is that \ immediately precedes the line feed to indicate a continuation, not that an orphan \ is valid on its own.

The reason that \(newline) is valid while \(otherchar)(newline) isn't is because \ immediately precedes another character that it is escaping, and it's possible that \(space) would have a meaning in the future, whereas \(newline) won't.

I agree with Alex on this, although I would be happy to make it a warning rather than an error so that it doesn't block compilation.

The point about comments is also significant: we previously said that comments should generally be treated like whitespace (SE-0037 <https://github.com/apple/swift-evolution/blob/master/proposals/0037-clarify-comments-and-operators.md&gt;\). This is a little different because it's still inside the string literal, but it's probably worth explicitly stating "we're still inside a string literal; you can't just put comments after the backslash".

Jordan

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

15

One more thing I wanted to add.

I would remove the restriction of

    An escape character at the end of the last line of a literal is an error, as no
    newlines follow.

from this proposal and allow the trailing backslash in the last line which won’t do harm to anything. The idea behind this is that one could annotate whitespaces in the last line:

>""" My very long string<space>\ in Swift :ghost:<space><space><space>\ """ |

Support this opinion. Otherwise, how we can explicitly preserve whitespaces in last line?

But in general, I wonder if this feature(newline escaping) can produce hard-to-find bugs. For example, currently we can't have such string:

let s = """
  ...
  In Windows you have paths like C:\
  ...
  """
// invalid escape sequence in literal

but with newline escaping, it seems(am I correct?) we can have such string without any error/warning, and the result text will not be what author planned. Depend on where such string will be used(template/JSON/SQL/etc), this can lead to not-obvious hard to find bugs.

Probably, this should not be just '\' but real escape sequence like '\_' (you can't have it currently in string, so seems OK to introduce it for newline escaping).

···

On 13.07.2017 9:24, Adrian Zubarev via swift-evolution wrote:

--
Adrian Zubarev
Sent with Airmail

On 13. July 2017 at 08:14:03, Adrian Zubarev (adrian.zubarev@devandartist.com > <mailto:adrian.zubarev@devandartist.com>) wrote:

Can you please elaborate?

—

In general I, as one of the co-authors, am for this additional change. However, personally I would be against adding the new line escaping feature to the single double-quote string literal, because it will create asymmetry.

For instance in a future proposal it’s likely we’d also allow the multi-line string literal |"""| to be written in a single line without any new line escaping, for strings that contain lots of double-quotes:

>let myString1 = """{"id": "OpenNew", "label": "Open New"}""" // old and current version let myString2 = "{\"id\": \"OpenNew\", \"label\": \"Open New\"}" |

Considering that proposal would be accepted we’d have two ways to express the multi-line string literal:

>// horizontal """Swift""" // vertical """ Swift """ |

Now about the previously mentioned asymmetry, if we’d accept in the current proposal and include new line escaping in a single double-quoted string literal eventually someone will find that again /inconsistent/ and ask to align >"""|-literal to allow:

>"""abc \ def""" // Symmetrical counterpart is from the current proposal "abc \ def" |

However this model was completely abandoned by the previous proposal and should be avoided at all cost even in the future, because it does not any value to the expressiveness, but only complicates the model.

—

On the other hand if we’re really considering adding this to |"|-literal, then it should be only possible if the |"|-literal gets a similar /vertical/ version like the |"""|-literal.

Notice that in that scenario:

  * we need borrow the indent mechanism from |"""|
  * the trailing |\| can be omitted after the last character on the current string line
  * the trailing |\| is only used for annotate trailing whitespaces (|"|-liteal
    does not add implicit new lines at all, it’s always should stay explicit about
    everything)

Something like that:

>// #1 " a\ b\ " == "ab" // #1.1 " a b " == "ab" // #2 " a \ b \ " == "a b " // #3 " c \ d \ " == " c d " |

By now it should be clearly visible that this extension for the |"|-literal does not add anything what the |"""|-literal cannot already solve nicely!

That said, let’s keep it simple and only add the |\| to vertical |"""|-literal.

--
Adrian Zubarev
Sent with Airmail

On 13. July 2017 at 02:10:30, Taylor Swift via swift-evolution >> (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) wrote:

as is, this will mess up the “collapse” feature in most text editors,, it should not be added unless indentation removal is added too

On Wed, Jul 12, 2017 at 7:48 PM, T.J. Usiyan via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

    +1

    Maintaining parity between single and multi line strings is nice even though
    breaking scope is a strong argument against actually using this with single
    line literals.

    On Wed, Jul 12, 2017 at 7:15 PM, Timothy Wood via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

        +1 This seems great to me. It seems worth calling out how escaping of
        backslashes and escaping of newlines interact for testing:

                let s = """
                line fragment ending in backslash \\\
                and
                line fragment ending in backslash \\\
                \\followed by line fragment starting with backslash
                """

        I would expect to get "line fragment ending in backslash \\and\nline
        fragment ending in backslash\\\\followed by line fragment starting with
        backslash”, that is, escaped backslashes at the end of line fragments
        should be retained, and whatever concatenates line fragments shouldn’t
        accidentally double-interpret backslashes.

        Alternatively:

                let s = """
                line ending in backslash \\
                and
                line ending in backslash \\
                \\followed by line starting with backslash
                """

        seems like it should produce the result "line ending in backslash
        \\\nand\nline ending in backslash\\\n\\followed by line starting with
        backslash”, that is, the consumption of escaped backslashes should happen
        before considering if there is an extra backslash on the end of the line
        for an escaped newline.

        -tim

        > On Jul 12, 2017, at 3:52 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
        >
        > Hello Swift community,
        >
        > Context: As part of winding down work on Swift 4, we are considering SE-0182 as a refinement to SE-0168. We are specifically not
        opening the floodgates for new proposals just yet, and it is not
        considered in scope to resyntax all of multi-line string literals. We’re
        just discussing this one potential small-scope refinement to an existing
        Swift 4 feature.
        >
        > The review of "String Newline Escaping" begins now and runs through July 17, 2017. The proposal is available here:
        > https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md
        <https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md&gt;
        >
        > 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
        <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;
        >
        > 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:
        >
        > 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:
        > https://github.com/apple/swift-evolution/blob/master/process.md
        <https://github.com/apple/swift-evolution/blob/master/process.md&gt;
        >
        > Thank you,
        >
        > Chris Lattner
        > Review Manager
        > _______________________________________________
        > swift-evolution mailing list
        > swift-evolution@swift.org <mailto:swift-evolution@swift.org>
        > https://lists.swift.org/mailman/listinfo/swift-evolution
        <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;

        _______________________________________________
        swift-evolution mailing list
        swift-evolution@swift.org <mailto:swift-evolution@swift.org>
        https://lists.swift.org/mailman/listinfo/swift-evolution
        <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;

    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    https://lists.swift.org/mailman/listinfo/swift-evolution
    <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

16

To add a data point, I migrated the Swift Package Manager to use Swift 4’s multi-line strings this weekend. Nearly all of the resulting multi-line strings required an ending new-line, forcing me to write the following pattern everywhere:

let text = ""”
    lorem ipsum dolor sit amet
    consectetur adipiscing elit
    sed do eiusmod

    “""

I agree that the Swift Package Manager is only one data-point, that mostly uses multi-line strings to append string content to files. Another project with SQL queries in multi-line strings might not really want an ending newline.

For reference, here is the Pull Request: Convert multi-line strings to the Swift 4 syntax by hartbit · Pull Request #1272 · apple/swift-package-manager · GitHub

David.

···

On 17 Jul 2017, at 13:32, John Holdsworth via swift-evolution <swift-evolution@swift.org> wrote:

As this review winds down it seems fair to say the response has been generally
favourable with some reservations about whether this should be applied to single
line strings as well. I’d include single line strings myself for consistency with multi-
line and with other languages myself but that isn’t the focus of this proposal.

There has also been some discussion about whether escaping the last newline should
be an error or ignored. For me this highlights that the final newline should be included
in the literal and could therefore be escaped when you want one without a newline at
the end which may or may not be the common use case as has been discussed before.

let text = """
    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod \
    tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, \
    quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.\
    """

let endsWithNewline = """
    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
    tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
    quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
    """

While multi-line strings would loose their pleasing symmetry from SE-0168 where initial
and final newlines are stripped I'd argue in response that text is generally asymmetric
with files generally having no newline at the start and a newline at the end. I can see
the arguments for both decisions though and could live with either.

-John

On 14 Jul 2017, at 18:17, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jul 14, 2017, at 10:00, Alex Blewitt <alblue@apple.com <mailto:alblue@apple.com>> wrote:

On 13 Jul 2017, at 23:14, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 14 Jul 2017, at 00:21, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md\]

This is a tiny, tiny point amidst the broader discussions others are having, but

  • All whitespace characters between \ and the newline are disregarded.

Why? Why bother allowing whitespace characters between \ and the newline?

The reasoning is to be consistent with trailing whitespace in the rest of the code: to leave that to a linter instead. Or to see it differently, even with whitespace between \ and the newline, the programmer’s intent is still clear. Why generate an error?

For the same reason that code allows (e.g.) a comment at the end of the line; you wouldn't expect (newline continuation) (comment) to mean the same thing as if generic whitespace were added at the end. The convention in other languages is that \ immediately precedes the line feed to indicate a continuation, not that an orphan \ is valid on its own.

The reason that \(newline) is valid while \(otherchar)(newline) isn't is because \ immediately precedes another character that it is escaping, and it's possible that \(space) would have a meaning in the future, whereas \(newline) won't.

I agree with Alex on this, although I would be happy to make it a warning rather than an error so that it doesn't block compilation.

The point about comments is also significant: we previously said that comments should generally be treated like whitespace (SE-0037 <https://github.com/apple/swift-evolution/blob/master/proposals/0037-clarify-comments-and-operators.md&gt;\). This is a little different because it's still inside the string literal, but it's probably worth explicitly stating "we're still inside a string literal; you can't just put comments after the backslash".

Jordan

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

17

Well even if my last pitch won’t happen it’s still would be possible to have trailing whitespaces in """ in it’s last line, the issue is that they aren’t visible. We do not want to bring that discussion back now, but we definitely will post Swift 4 release.

That said the backslash in the last line simply should do nothing but still be allowed. This won’t complicate anything nor would it do any harm.

···

—

About c:\ well in that case it might look like a bug but it isn’t because you should always keep in mind that \ as a character should be escaped as well, so it should be c:\\ anyways. If you than would want to break your line then you’ll end up with c:\\\ which might look ugly but it’s a consequence of using \ for our main purpose.

--
Adrian Zubarev
Sent with Airmail

On 13. July 2017 at 13:28:48, Vladimir.S (svabox@gmail.com) wrote:

On 13.07.2017 9:24, Adrian Zubarev via swift-evolution wrote:

One more thing I wanted to add.

I would remove the restriction of

An escape character at the end of the last line of a literal is an error, as no
newlines follow.

from this proposal and allow the trailing backslash in the last line which won’t do
harm to anything. The idea behind this is that one could annotate whitespaces in the
last line:

>""" My very long string<space>\ in Swift :ghost:<space><space><space>\ """ |

Support this opinion. Otherwise, how we can explicitly preserve whitespaces in last line?

But in general, I wonder if this feature(newline escaping) can produce hard-to-find
bugs. For example, currently we can't have such string:

let s = """
...
In Windows you have paths like C:\
...
"""
// invalid escape sequence in literal

but with newline escaping, it seems(am I correct?) we can have such string without
any error/warning, and the result text will not be what author planned. Depend on
where such string will be used(template/JSON/SQL/etc), this can lead to not-obvious
hard to find bugs.

Probably, this should not be just '\' but real escape sequence like '\_' (you can't
have it currently in string, so seems OK to introduce it for newline escaping).

--
Adrian Zubarev
Sent with Airmail

On 13. July 2017 at 08:14:03, Adrian Zubarev (adrian.zubarev@devandartist.com > <mailto:adrian.zubarev@devandartist.com>) wrote:

Can you please elaborate?

—

In general I, as one of the co-authors, am for this additional change. However,
personally I would be against adding the new line escaping feature to the single
double-quote string literal, because it will create asymmetry.

For instance in a future proposal it’s likely we’d also allow the multi-line string
literal |"""| to be written in a single line without any new line escaping, for
strings that contain lots of double-quotes:

>let myString1 = """{"id": "OpenNew", "label": "Open New"}""" // old and current
version let myString2 = "{\"id\": \"OpenNew\", \"label\": \"Open New\"}" |

Considering that proposal would be accepted we’d have two ways to express the
multi-line string literal:

>// horizontal """Swift""" // vertical """ Swift """ |

Now about the previously mentioned asymmetry, if we’d accept in the current
proposal and include new line escaping in a single double-quoted string literal
eventually someone will find that again /inconsistent/ and ask to align
>"""|-literal to allow:

>"""abc \ def""" // Symmetrical counterpart is from the current proposal "abc \ def" |

However this model was completely abandoned by the previous proposal and should be
avoided at all cost even in the future, because it does not any value to the
expressiveness, but only complicates the model.

—

On the other hand if we’re really considering adding this to |"|-literal, then it
should be only possible if the |"|-literal gets a similar /vertical/ version like
the |"""|-literal.

Notice that in that scenario:

* we need borrow the indent mechanism from |"""|
* the trailing |\| can be omitted after the last character on the current string line
* the trailing |\| is only used for annotate trailing whitespaces (|"|-liteal
does not add implicit new lines at all, it’s always should stay explicit about
everything)

Something like that:

>// #1 " a\ b\ " == "ab" // #1.1 " a b " == "ab" // #2 " a \ b \ " == "a b " // #3 "
c \ d \ " == " c d " |

By now it should be clearly visible that this extension for the |"|-literal does
not add anything what the |"""|-literal cannot already solve nicely!

That said, let’s keep it simple and only add the |\| to vertical |"""|-literal.

--
Adrian Zubarev
Sent with Airmail

On 13. July 2017 at 02:10:30, Taylor Swift via swift-evolution >> (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) wrote:

as is, this will mess up the “collapse” feature in most text editors,, it should
not be added unless indentation removal is added too

On Wed, Jul 12, 2017 at 7:48 PM, T.J. Usiyan via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

+1

Maintaining parity between single and multi line strings is nice even though
breaking scope is a strong argument against actually using this with single
line literals.

On Wed, Jul 12, 2017 at 7:15 PM, Timothy Wood via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

+1 This seems great to me. It seems worth calling out how escaping of
backslashes and escaping of newlines interact for testing:

let s = """
line fragment ending in backslash \\\
and
line fragment ending in backslash \\\
\\followed by line fragment starting with backslash
"""

I would expect to get "line fragment ending in backslash \\and\nline
fragment ending in backslash\\\\followed by line fragment starting with
backslash”, that is, escaped backslashes at the end of line fragments
should be retained, and whatever concatenates line fragments shouldn’t
accidentally double-interpret backslashes.

Alternatively:

let s = """
line ending in backslash \\
and
line ending in backslash \\
\\followed by line starting with backslash
"""

seems like it should produce the result "line ending in backslash
\\\nand\nline ending in backslash\\\n\\followed by line starting with
backslash”, that is, the consumption of escaped backslashes should happen
before considering if there is an extra backslash on the end of the line
for an escaped newline.

-tim

> On Jul 12, 2017, at 3:52 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> Hello Swift community,
>
> Context: As part of winding down work on Swift 4, we are considering SE-0182 as a refinement to SE-0168. We are specifically not
opening the floodgates for new proposals just yet, and it is not
considered in scope to resyntax all of multi-line string literals. We’re
just discussing this one potential small-scope refinement to an existing
Swift 4 feature.
>
>
> The review of "String Newline Escaping" begins now and runs through July 17, 2017. The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md
<https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md&gt;
>
> 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
<https://lists.swift.org/mailman/listinfo/swift-evolution&gt;
>
> 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:
>
> 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:
> https://github.com/apple/swift-evolution/blob/master/process.md
<https://github.com/apple/swift-evolution/blob/master/process.md&gt;
>
>
> Thank you,
>
> Chris Lattner
> Review Manager
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
<https://lists.swift.org/mailman/listinfo/swift-evolution&gt;

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
<https://lists.swift.org/mailman/listinfo/swift-evolution&gt;

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
<https://lists.swift.org/mailman/listinfo/swift-evolution&gt;

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

18

Well even if my last pitch won’t happen it’s still would be possible to have trailing whitespaces in |"""| in it’s last line, the issue is that they aren’t visible. We do not want to bring that discussion back now, but we definitely will post Swift 4 release.

Yes, if one's editor will not drop trailing spaces in source lines. The feature can't rely on belief that editor will not delete trailing spaces in source lines during the save operation. Especially, if the same source file can be edited by different devs/editors.

That said the backslash in the last line simply should do nothing but still be allowed. This won’t complicate anything nor would it do any harm.

—

About |c:\| well in that case it might look like a /bug/ but it isn’t because you should always keep in mind that |\| as a character should be escaped as well, so it should be |c:\\| anyways. If you than would want to break your line then you’ll end up with |c:\\\| which might look ugly but it’s a consequence of using |\| for our main purpose.

Again, currently Swift prevents you from this mistake. You can't just write
"""
...
c:\
...
"""

(and also can't write incorrect escape sequence like "\!")

"ERROR at line x, col xx: invalid escape sequence in literal"

With new feature of newline escaping with backslash - Swift will not help you in this particular case. Given that multiline strings help to copy&paste text into source - such cases are possible.

Yes, I don't think this case is very important, and editor can show that backslash with different color, but it shows that suggested solution can, in some cases, produce problems that were not possible before. So just wanted to discuss.

···

On 13.07.2017 14:41, Adrian Zubarev wrote:

--
Adrian Zubarev
Sent with Airmail

On 13. July 2017 at 13:28:48, Vladimir.S (svabox@gmail.com <mailto:svabox@gmail.com>) > wrote:

On 13.07.2017 9:24, Adrian Zubarev via swift-evolution wrote:
> One more thing I wanted to add.
> > I would remove the restriction of
> > An escape character at the end of the last line of a literal is an error, as no
> newlines follow.
> > from this proposal and allow the trailing backslash in the last line which won’t do > harm to anything. The idea behind this is that one could annotate whitespaces in the > last line:
> > >""" My very long string<space>\ in Swift :ghost:<space><space><space>\ """ |
>

Support this opinion. Otherwise, how we can explicitly preserve whitespaces in last line?

But in general, I wonder if this feature(newline escaping) can produce hard-to-find
bugs. For example, currently we can't have such string:

let s = """
...
In Windows you have paths like C:\
...
"""
// invalid escape sequence in literal

but with newline escaping, it seems(am I correct?) we can have such string without
any error/warning, and the result text will not be what author planned. Depend on
where such string will be used(template/JSON/SQL/etc), this can lead to not-obvious
hard to find bugs.

Probably, this should not be just '\' but real escape sequence like '\_' (you can't
have it currently in string, so seems OK to introduce it for newline escaping).

> > > -- > Adrian Zubarev
> Sent with Airmail
> > On 13. July 2017 at 08:14:03, Adrian Zubarev (adrian.zubarev@devandartist.com >> > <mailto:adrian.zubarev@devandartist.com>) wrote:
> >> Can you please elaborate?
>>
>> —
>>
>> In general I, as one of the co-authors, am for this additional change. However, >> personally I would be against adding the new line escaping feature to the single >> double-quote string literal, because it will create asymmetry.
>>
>> For instance in a future proposal it’s likely we’d also allow the multi-line string >> literal |"""| to be written in a single line without any new line escaping, for >> strings that contain lots of double-quotes:
>>
>> >let myString1 = """{"id": "OpenNew", "label": "Open New"}""" // old and current >> version let myString2 = "{\"id\": \"OpenNew\", \"label\": \"Open New\"}" |
>>
>> Considering that proposal would be accepted we’d have two ways to express the >> multi-line string literal:
>>
>> >// horizontal """Swift""" // vertical """ Swift """ |
>>
>> Now about the previously mentioned asymmetry, if we’d accept in the current >> proposal and include new line escaping in a single double-quoted string literal >> eventually someone will find that again /inconsistent/ and ask to align >> >"""|-literal to allow:
>>
>> >"""abc \ def""" // Symmetrical counterpart is from the current proposal "abc \ def" |
>>
>> However this model was completely abandoned by the previous proposal and should be >> avoided at all cost even in the future, because it does not any value to the >> expressiveness, but only complicates the model.
>>
>> —
>>
>> On the other hand if we’re really considering adding this to |"|-literal, then it >> should be only possible if the |"|-literal gets a similar /vertical/ version like >> the |"""|-literal.
>>
>> Notice that in that scenario:
>>
>> * we need borrow the indent mechanism from |"""|
>> * the trailing |\| can be omitted after the last character on the current string line
>> * the trailing |\| is only used for annotate trailing whitespaces (|"|-liteal
>> does not add implicit new lines at all, it’s always should stay explicit about
>> everything)
>>
>> Something like that:
>>
>> >// #1 " a\ b\ " == "ab" // #1.1 " a b " == "ab" // #2 " a \ b \ " == "a b " // #3 " >> c \ d \ " == " c d " |
>>
>> By now it should be clearly visible that this extension for the |"|-literal does >> not add anything what the |"""|-literal cannot already solve nicely!
>>
>> That said, let’s keep it simple and only add the |\| to vertical |"""|-literal.
>>
>> -- >> Adrian Zubarev
>> Sent with Airmail
>>
>> On 13. July 2017 at 02:10:30, Taylor Swift via swift-evolution >> >> (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) wrote:
>>
>>> as is, this will mess up the “collapse” feature in most text editors,, it should >>> not be added unless indentation removal is added too
>>>
>>> On Wed, Jul 12, 2017 at 7:48 PM, T.J. Usiyan via swift-evolution >> >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>> +1
>>>
>>> Maintaining parity between single and multi line strings is nice even though
>>> breaking scope is a strong argument against actually using this with single
>>> line literals.
>>>
>>> On Wed, Jul 12, 2017 at 7:15 PM, Timothy Wood via swift-evolution >> >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>> +1 This seems great to me. It seems worth calling out how escaping of
>>> backslashes and escaping of newlines interact for testing:
>>>
>>> let s = """
>>> line fragment ending in backslash \\\
>>> and
>>> line fragment ending in backslash \\\
>>> \\followed by line fragment starting with backslash
>>> """
>>>
>>> I would expect to get "line fragment ending in backslash \\and\nline
>>> fragment ending in backslash\\\\followed by line fragment starting with
>>> backslash”, that is, escaped backslashes at the end of line fragments
>>> should be retained, and whatever concatenates line fragments shouldn’t
>>> accidentally double-interpret backslashes.
>>>
>>> Alternatively:
>>>
>>> let s = """
>>> line ending in backslash \\
>>> and
>>> line ending in backslash \\
>>> \\followed by line starting with backslash
>>> """
>>>
>>> seems like it should produce the result "line ending in backslash
>>> \\\nand\nline ending in backslash\\\n\\followed by line starting with
>>> backslash”, that is, the consumption of escaped backslashes should happen
>>> before considering if there is an extra backslash on the end of the line
>>> for an escaped newline.
>>>
>>> -tim
>>>
>>> > On Jul 12, 2017, at 3:52 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> >
>>> > Hello Swift community,
>>> >
>>> > Context: As part of winding down work on Swift 4, we are considering SE-0182 as a refinement to SE-0168. We are specifically not
>>> opening the floodgates for new proposals just yet, and it is not
>>> considered in scope to resyntax all of multi-line string literals. We’re
>>> just discussing this one potential small-scope refinement to an existing
>>> Swift 4 feature.
>>> >
>>> > The review of "String Newline Escaping" begins now and runs through July 17, 2017. The proposal is available here:
>>> > https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md
>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md&gt;
>>> >
>>> > 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
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;
>>> >
>>> > 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:
>>> >
>>> > 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:
>>> > https://github.com/apple/swift-evolution/blob/master/process.md
>>> <https://github.com/apple/swift-evolution/blob/master/process.md&gt;
>>> >
>>> > Thank you,
>>> >
>>> > Chris Lattner
>>> > Review Manager
>>> > _______________________________________________
>>> > swift-evolution mailing list
>>> > swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> > > > _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

19

I only had a quick glance but I quickly noticed that there were quite a lot cases which didn’t require a trailing new line, but if we’d revert this decision would require a trailing \ over and over.

That would make the simplest multi-line string literal not that simple anymore:

"""
abc
""" == "abc\n"
Which means we’ll see a lot of cases like:

"""
abc\
"""
I obviously cannot foresee which cases would dominate, but I’d keep it like it is. Furthermore, we wanted to avoid this talk in this review anyway.

On the other side the ability to write \ in the last line can be used in cases like this:

let signatureTemplate = """
    Adrian Zubarev
    """

// At some later point
let clientName = "Airmail"
print(signatureTemplate + clientName)

// prints:
// Adrian Zubarev
// Sent with Airmail
And I still don’t see the need for adding this feature to " literals. That’s only my personal opinion! We don’t want to align Swift with other languages, especially not with the C-family. Sure we want interoperability, but that can be achieved differently. Our goal is to borrow best practices or improve things know from other languages so that we can avoid ugliness baked into other programming languages. If we’re speak about consistency for \ than we should speak about consistency between the two literals and not other languages.

// #1
// What does this version add to Swift (forget other languages)?!
_ = "Swift \
is awesome"

// #2 - Consistent counterpart for #1
// (already rejected in SE-168 for good reasons)
_ = """Swift \
is awesome"""

// In theory #2 still would have indent stripping.
// This makes #1 inconsistent!
_ = """Swift \
    is \
    awesome"""
     
// I also don't think we want to debate about the
// combination like the following one:
_ = """Swift \
    is \
    awesome
    """
     
// #3
"""
Abc
Def
"""

// #4 - Consistent counterpart for #3
// `"`- literal should stay explicit about it's content.
// Does this add anything that `"""` cannot solve better? - No!
"
Abc\n
Def\n
"

···

Sent with \

--
Adrian Zubarev
Sent with Airmail

On 17. July 2017 at 13:43:07, David Hart via swift-evolution (swift-evolution@swift.org) wrote:

To add a data point, I migrated the Swift Package Manager to use Swift 4’s multi-line strings this weekend. Nearly all of the resulting multi-line strings required an ending new-line, forcing me to write the following pattern everywhere:

let text = ""”
lorem ipsum dolor sit amet
consectetur adipiscing elit
sed do eiusmod

“&quot;&quot;

I agree that the Swift Package Manager is only one data-point, that mostly uses multi-line strings to append string content to files. Another project with SQL queries in multi-line strings might not really want an ending newline.

For reference, here is the Pull Request: Convert multi-line strings to the Swift 4 syntax by hartbit · Pull Request #1272 · apple/swift-package-manager · GitHub

David.

On 17 Jul 2017, at 13:32, John Holdsworth via swift-evolution <swift-evolution@swift.org> wrote:

As this review winds down it seems fair to say the response has been generally
favourable with some reservations about whether this should be applied to single
line strings as well. I’d include single line strings myself for consistency with multi-
line and with other languages myself but that isn’t the focus of this proposal.

There has also been some discussion about whether escaping the last newline should
be an error or ignored. For me this highlights that the final newline should be included
in the literal and could therefore be escaped when you want one without a newline at
the end which may or may not be the common use case as has been discussed before.

let text = """
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod \
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, \
quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.\
"""

let endsWithNewline = """
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
"""

While multi-line strings would loose their pleasing symmetry from SE-0168 where initial
and final newlines are stripped I'd argue in response that text is generally asymmetric
with files generally having no newline at the start and a newline at the end. I can see
the arguments for both decisions though and could live with either.

-John

On 14 Jul 2017, at 18:17, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

On Jul 14, 2017, at 10:00, Alex Blewitt <alblue@apple.com> wrote:

On 13 Jul 2017, at 23:14, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

On 14 Jul 2017, at 00:21, Jordan Rose <jordan_rose@apple.com> wrote:

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md\]

This is a tiny, tiny point amidst the broader discussions others are having, but

• All whitespace characters between \ and the newline are disregarded.

Why? Why bother allowing whitespace characters between \ and the newline?

The reasoning is to be consistent with trailing whitespace in the rest of the code: to leave that to a linter instead. Or to see it differently, even with whitespace between \ and the newline, the programmer’s intent is still clear. Why generate an error?

For the same reason that code allows (e.g.) a comment at the end of the line; you wouldn't expect (newline continuation) (comment) to mean the same thing as if generic whitespace were added at the end. The convention in other languages is that \ immediately precedes the line feed to indicate a continuation, not that an orphan \ is valid on its own.

The reason that \(newline) is valid while \(otherchar)(newline) isn't is because \ immediately precedes another character that it is escaping, and it's possible that \(space) would have a meaning in the future, whereas \(newline) won't.

I agree with Alex on this, although I would be happy to make it a warning rather than an error so that it doesn't block compilation.

The point about comments is also significant: we previously said that comments should generally be treated like whitespace (SE-0037). This is a little different because it's still inside the string literal, but it's probably worth explicitly stating "we're still inside a string literal; you can't just put comments after the backslash".

Jordan

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

20

Can’t you use ... eiusmod\n instead of a blank line?

-Chris

···

On Jul 17, 2017, at 4:43 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

To add a data point, I migrated the Swift Package Manager to use Swift 4’s multi-line strings this weekend. Nearly all of the resulting multi-line strings required an ending new-line, forcing me to write the following pattern everywhere:

let text = ""”
    lorem ipsum dolor sit amet
    consectetur adipiscing elit
    sed do eiusmod

    “”"