[swift-evolution] [Review] SE-0182 - String Newline Escaping

[Xiaodi Wu]

On Wed, Jul 12, 2017 at 5:52 PM, Chris Lattner via swift-evolution <
swift-evolution at 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?
>

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.


> 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170713/b324146b/attachment.html>