<html><head><style>
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
padding:1em;
margin:auto;
background:#fefefe;
}
h1, h2, h3, h4, h5, h6 {
font-weight: bold;
}
h1 {
color: #000000;
font-size: 28pt;
}
h2 {
border-bottom: 1px solid #CCCCCC;
color: #000000;
font-size: 24px;
}
h3 {
font-size: 18px;
}
h4 {
font-size: 16px;
}
h5 {
font-size: 14px;
}
h6 {
color: #777777;
background-color: inherit;
font-size: 14px;
}
hr {
height: 0.2em;
border: 0;
color: #CCCCCC;
background-color: #CCCCCC;
display: inherit;
}
p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0;
}
a, a:visited {
color: #4183C4;
background-color: inherit;
text-decoration: none;
}
#message {
border-radius: 6px;
border: 1px solid #ccc;
display:block;
width:100%;
height:60px;
margin:6px 0px;
}
button, #ws {
font-size: 12 pt;
padding: 4px 6px;
border-radius: 5px;
border: 1px solid #bbb;
background-color: #eee;
}
code, pre, #ws, #message {
font-family: Monaco;
font-size: 10pt;
border-radius: 3px;
background-color: #F8F8F8;
color: inherit;
}
code {
border: 1px solid #EAEAEA;
margin: 0 2px;
padding: 0 5px;
}
pre {
border: 1px solid #CCCCCC;
overflow: auto;
padding: 4px 8px;
}
pre > code {
border: 0;
margin: 0;
padding: 0;
}
#ws { background-color: #f8f8f8; }
.bloop_markdown table {
border-collapse: collapse;
font-family: Helvetica, arial, freesans, clean, sans-serif;
color: rgb(51, 51, 51);
font-size: 15px; line-height: 25px;
padding: 0; }
.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }
.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }
.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
.bloop_markdown blockquote{
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
code, pre, #ws, #message {
word-break: normal;
word-wrap: normal;
}
hr {
display: inherit;
}
.bloop_markdown :first-child {
-webkit-margin-before: 0;
}
code, pre, #ws, #message {
font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}
.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_markdown"><p>Well even if my last pitch won’t happen it’s still would be possible to have trailing whitespaces in <code>"""</code> 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. </p>
<p>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.</p>
<p>—</p>
<p>About <code>c:\</code> well in that case it might look like a <em>bug</em> but it isn’t because you should always keep in mind that <code>\</code> as a character should be escaped as well, so it should be <code>c:\\</code> anyways. If you than would want to break your line then you’ll end up with <code>c:\\\</code> which might look ugly but it’s a consequence of using <code>\</code> for our main purpose.</p>
<p></p></div><div class="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1499945652691063040" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">On 13. July 2017 at 13:28:48, Vladimir.S (<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>On 13.07.2017 9:24, Adrian Zubarev via swift-evolution wrote:
<br>> One more thing I wanted to add.
<br>>
<br>> I would remove the restriction of
<br>>
<br>> An escape character at the end of the last line of a literal is an error, as no
<br>> newlines follow.
<br>>
<br>> from this proposal and allow the trailing backslash in the last line which won’t do
<br>> harm to anything. The idea behind this is that one could annotate whitespaces in the
<br>> last line:
<br>>
<br>> |""" My very long string<space>\ in Swift 👻<space><space><space>\ """ |
<br>>
<br>
<br>Support this opinion. Otherwise, how we can explicitly preserve whitespaces in last line?
<br>
<br>
<br>But in general, I wonder if this feature(newline escaping) can produce hard-to-find
<br>bugs. For example, currently we can't have such string:
<br>
<br>let s = """
<br> ...
<br> In Windows you have paths like C:\
<br> ...
<br> """
<br>// invalid escape sequence in literal
<br>
<br>but with newline escaping, it seems(am I correct?) we can have such string without
<br>any error/warning, and the result text will not be what author planned. Depend on
<br>where such string will be used(template/JSON/SQL/etc), this can lead to not-obvious
<br>hard to find bugs.
<br>
<br>Probably, this should not be just '\' but real escape sequence like '\_' (you can't
<br>have it currently in string, so seems OK to introduce it for newline escaping).
<br>
<br>>
<br>>
<br>> --
<br>> Adrian Zubarev
<br>> Sent with Airmail
<br>>
<br>> On 13. July 2017 at 08:14:03, Adrian Zubarev (adrian.zubarev@devandartist.com
<br>> <mailto:adrian.zubarev@devandartist.com>) wrote:
<br>>
<br>>> Can you please elaborate?
<br>>>
<br>>> —
<br>>>
<br>>> In general I, as one of the co-authors, am for this additional change. However,
<br>>> personally I would be against adding the new line escaping feature to the single
<br>>> double-quote string literal, because it will create asymmetry.
<br>>>
<br>>> For instance in a future proposal it’s likely we’d also allow the multi-line string
<br>>> literal |"""| to be written in a single line without any new line escaping, for
<br>>> strings that contain lots of double-quotes:
<br>>>
<br>>> |let myString1 = """{"id": "OpenNew", "label": "Open New"}""" // old and current
<br>>> version let myString2 = "{\"id\": \"OpenNew\", \"label\": \"Open New\"}" |
<br>>>
<br>>> Considering that proposal would be accepted we’d have two ways to express the
<br>>> multi-line string literal:
<br>>>
<br>>> |// horizontal """Swift""" // vertical """ Swift """ |
<br>>>
<br>>> Now about the previously mentioned asymmetry, if we’d accept in the current
<br>>> proposal and include new line escaping in a single double-quoted string literal
<br>>> eventually someone will find that again /inconsistent/ and ask to align
<br>>> |"""|-literal to allow:
<br>>>
<br>>> |"""abc \ def""" // Symmetrical counterpart is from the current proposal "abc \ def" |
<br>>>
<br>>> However this model was completely abandoned by the previous proposal and should be
<br>>> avoided at all cost even in the future, because it does not any value to the
<br>>> expressiveness, but only complicates the model.
<br>>>
<br>>> —
<br>>>
<br>>> On the other hand if we’re really considering adding this to |"|-literal, then it
<br>>> should be only possible if the |"|-literal gets a similar /vertical/ version like
<br>>> the |"""|-literal.
<br>>>
<br>>> Notice that in that scenario:
<br>>>
<br>>> * we need borrow the indent mechanism from |"""|
<br>>> * the trailing |\| can be omitted after the last character on the current string line
<br>>> * the trailing |\| is only used for annotate trailing whitespaces (|"|-liteal
<br>>> does not add implicit new lines at all, it’s always should stay explicit about
<br>>> everything)
<br>>>
<br>>> Something like that:
<br>>>
<br>>> |// #1 " a\ b\ " == "ab" // #1.1 " a b " == "ab" // #2 " a \ b \ " == "a b " // #3 "
<br>>> c \ d \ " == " c d " |
<br>>>
<br>>> By now it should be clearly visible that this extension for the |"|-literal does
<br>>> not add anything what the |"""|-literal cannot already solve nicely!
<br>>>
<br>>> That said, let’s keep it simple and only add the |\| to vertical |"""|-literal.
<br>>>
<br>>>
<br>>>
<br>>> --
<br>>> Adrian Zubarev
<br>>> Sent with Airmail
<br>>>
<br>>> On 13. July 2017 at 02:10:30, Taylor Swift via swift-evolution
<br>>> (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) wrote:
<br>>>
<br>>>> as is, this will mess up the “collapse” feature in most text editors,, it should
<br>>>> not be added unless indentation removal is added too
<br>>>>
<br>>>> On Wed, Jul 12, 2017 at 7:48 PM, T.J. Usiyan via swift-evolution
<br>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
<br>>>>
<br>>>> +1
<br>>>>
<br>>>> Maintaining parity between single and multi line strings is nice even though
<br>>>> breaking scope is a strong argument against actually using this with single
<br>>>> line literals.
<br>>>>
<br>>>> On Wed, Jul 12, 2017 at 7:15 PM, Timothy Wood via swift-evolution
<br>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
<br>>>>
<br>>>>
<br>>>> +1 This seems great to me. It seems worth calling out how escaping of
<br>>>> backslashes and escaping of newlines interact for testing:
<br>>>>
<br>>>>
<br>>>> let s = """
<br>>>> line fragment ending in backslash \\\
<br>>>> and
<br>>>> line fragment ending in backslash \\\
<br>>>> \\followed by line fragment starting with backslash
<br>>>> """
<br>>>>
<br>>>> I would expect to get "line fragment ending in backslash \\and\nline
<br>>>> fragment ending in backslash\\\\followed by line fragment starting with
<br>>>> backslash”, that is, escaped backslashes at the end of line fragments
<br>>>> should be retained, and whatever concatenates line fragments shouldn’t
<br>>>> accidentally double-interpret backslashes.
<br>>>>
<br>>>> Alternatively:
<br>>>>
<br>>>> let s = """
<br>>>> line ending in backslash \\
<br>>>> and
<br>>>> line ending in backslash \\
<br>>>> \\followed by line starting with backslash
<br>>>> """
<br>>>>
<br>>>> seems like it should produce the result "line ending in backslash
<br>>>> \\\nand\nline ending in backslash\\\n\\followed by line starting with
<br>>>> backslash”, that is, the consumption of escaped backslashes should happen
<br>>>> before considering if there is an extra backslash on the end of the line
<br>>>> for an escaped newline.
<br>>>>
<br>>>> -tim
<br>>>>
<br>>>>
<br>>>>
<br>>>> > On Jul 12, 2017, at 3:52 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
<br>>>> >
<br>>>> > Hello Swift community,
<br>>>> >
<br>>>> > 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
<br>>>> opening the floodgates for new proposals just yet, and it is not
<br>>>> considered in scope to resyntax all of multi-line string literals. We’re
<br>>>> just discussing this one potential small-scope refinement to an existing
<br>>>> Swift 4 feature.
<br>>>> >
<br>>>> >
<br>>>> > The review of "String Newline Escaping" begins now and runs through July 17, 2017. The proposal is available here:
<br>>>> > https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md
<br>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md>
<br>>>> >
<br>>>> > Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
<br>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
<br>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
<br>>>> >
<br>>>> > or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal
<br>>>> link at the top of the message:
<br>>>> >
<br>>>> > What goes into a review?
<br>>>> >
<br>>>> > The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine
<br>>>> the direction of Swift. When writing your review, here are some questions
<br>>>> you might want to answer in your review:
<br>>>> >
<br>>>> > • What is your evaluation of the proposal?
<br>>>> > • Is the problem being addressed significant enough to warrant a change to Swift?
<br>>>> > • Does this proposal fit well with the feel and direction of Swift?
<br>>>> > • If you have used other languages or libraries with a similar feature, how do you feel that this proposal
<br>>>> compares to those?
<br>>>> > • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
<br>>>> >
<br>>>> > More information about the Swift evolution process is available at:
<br>>>> > https://github.com/apple/swift-evolution/blob/master/process.md
<br>>>> <https://github.com/apple/swift-evolution/blob/master/process.md>
<br>>>> >
<br>>>> >
<br>>>> > Thank you,
<br>>>> >
<br>>>> > Chris Lattner
<br>>>> > Review Manager
<br>>>> > _______________________________________________
<br>>>> > swift-evolution mailing list
<br>>>> > swift-evolution@swift.org <mailto:swift-evolution@swift.org>
<br>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
<br>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
<br>>>>
<br>>>> _______________________________________________
<br>>>> swift-evolution mailing list
<br>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
<br>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
<br>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
<br>>>>
<br>>>>
<br>>>>
<br>>>> _______________________________________________
<br>>>> swift-evolution mailing list
<br>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
<br>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
<br>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
<br>>>>
<br>>>>
<br>>>> _______________________________________________
<br>>>> swift-evolution mailing list
<br>>>> swift-evolution@swift.org
<br>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
<br>>
<br>>
<br>>
<br>> _______________________________________________
<br>> swift-evolution mailing list
<br>> swift-evolution@swift.org
<br>> https://lists.swift.org/mailman/listinfo/swift-evolution
<br>>
<br></div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>