<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Proposal Link: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md</a><div class=""><br class=""></div><div class="">Hello Swift Community,</div><div class=""><br class=""></div><div class="">The review of SE-0168: "Multi-Line String Literals" ran from April 6...12, 2017. The proposal is <b class="">accepted with revisions. </b>Community feedback was largely positive on the idea, though the discussion highlighted several under-specified aspects.</div><div class=""><br class=""></div><div class="">- Questions arose about whether text could appear on the same line as the opening and closing delimiter, and how that would interact with the de-indentation algorithm. The core team feels that it is important to keep this feature focused on its purpose of allowing the easy embedding of pasted blocks of text, so <b class="">text inside the literal on the same line as either delimiter should be disallowed.</b></div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">// Allowed, equal to "foo\nbar"</div><div class="">"""</div><div class=""> foo</div><div class=""> bar</div><div class=""> """</div><div class=""><br class=""></div><div class="">// Not allowed</div><div class="">"""foo</div><div class=""> bar</div><div class=""> """</div><div class=""><br class=""></div><div class="">// Not allowed</div><div class="">"""</div><div class=""> foo</div><div class=""> bar"""</div><div class=""><br class=""></div></blockquote>This keeps the model straightforward to describe: a <b class="">single newline </b>is always stripped after the opening delimiter and before the closing one, and the closing delimiter's position always determines the indentation level of the entire literal. The core team acknowledges that single-line triple quoted strings have other uses in other languages, such as to avoid excessive escaping in a string that contains lots of literal quotes, but supporting that alongside the indentation-stripping behavior leads to a lot of subtlety, and there could be other solutions to the escaping problem down the line, such as raw strings. If nothing else, single-line triple quoted strings can be considered later as an additive feature.<div class=""><br class=""></div><div class="">- The core team also believes that <b class="">underindentation or inconsistent tab/space usage within the indentation should be an error.</b> Every line inside the literal must begin with the exact sequence of spaces and tabs that precedes the closing delimiter.<div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>"""</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><tab><space>this is OK</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><space><space>this is an error</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><space><tab>this is also an error</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><tab>under-indenting is an error too</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><tab><space><space>but you can go nuts after the indentation all you want</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><tab><space><tab>you do you</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><tab><space>"""<br class=""><div class=""><br class=""></div><div class="">- The quoted string should <b class="">normalize newlines</b> to \n in the value of the literal, regardless of whether the source file uses \n (Unix), \r\n (Windows), or \r (classic Mac) line endings. Likewise, when the compiler strips the initial and final newline from the literal value, it will strip one of any of the \n, \r\n, or \r line-ending sequences from both ends of the literal.</div></div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// equal to "foo\nfoo\nfoo\nfoo"</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>"""^J</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span> foo^M^J</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span> foo^J</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span> foo^M</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span> foo^M</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span> """</div><div class=""><br class=""></div><div class="">- It should be clarified that <b class="">multiline strings support the same escapes and interpolations</b> as single-line strings. This allows a literal """ to be written \""". Discussion on the list raised the idea of allowing a line to end with \ to "escape" the newline and elide it from the value of the literal; the core team had concerns about only allowing that inside multi-line literals and felt that that could also be considered later as an additive feature.</div><div class=""><br class=""></div><div class="">Thanks John, Brent, and Tyler for the original proposal, and thanks to everyone who participated in the discussion!</div><div class=""><br class=""></div><div class="">-Joe</div><div class="">Review Manager</div></div></body></html>