<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>If I understood Joe correctly he said it gets stripped:</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">"<span style="background-color: rgba(255, 255, 255, 0);">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."</span><br><br>So I think it would be "foo\nbar". </div><div><br>On Apr 19, 2017, at 4:52 PM, Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span>On 19.04.2017 23:03, Joe Groff via swift-evolution wrote:</span><br><blockquote type="cite"><span>Proposal Link: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md">https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md</a></span><br></blockquote><blockquote type="cite"><span>Hello Swift Community,</span><br></blockquote><blockquote type="cite"><span>The review of SE-0168: "Multi-Line String Literals" ran from April 6...12, 2017. The proposal is *accepted with revisions. *Community feedback was largely positive on the idea, though the discussion highlighted several under-specified aspects.</span><br></blockquote><blockquote type="cite"><span>- 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 *text inside the literal on the same line as either delimiter should be disallowed.*</span><br></blockquote><blockquote type="cite"><span> // Allowed, equal to "foo\nbar"</span><br></blockquote><blockquote type="cite"><span> """</span><br></blockquote><blockquote type="cite"><span> foo</span><br></blockquote><blockquote type="cite"><span> bar</span><br></blockquote><blockquote type="cite"><span> """</span><br></blockquote><span></span><br><span>Could you clarify, shouldn't this be equal to "foo\nbar\n" ? I.e. with trailing \n for "bar" line?</span><br><span>I didn't find any clarification about the injecting of line-end for last text line(not for the """ delimiter).</span><br><span></span><br><blockquote type="cite"><span> // Not allowed</span><br></blockquote><blockquote type="cite"><span> """foo</span><br></blockquote><blockquote type="cite"><span> bar</span><br></blockquote><blockquote type="cite"><span> """</span><br></blockquote><blockquote type="cite"><span> // Not allowed</span><br></blockquote><blockquote type="cite"><span> """</span><br></blockquote><blockquote type="cite"><span> foo</span><br></blockquote><blockquote type="cite"><span> bar"""</span><br></blockquote><blockquote type="cite"><span>This keeps the model straightforward to describe: a *single newline *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.</span><br></blockquote><blockquote type="cite"><span>- The core team also believes that *underindentation or inconsistent tab/space usage within the indentation should be an error.* Every line inside the literal must begin with the exact sequence of spaces and tabs that precedes the closing delimiter.</span><br></blockquote><blockquote type="cite"><span>"""</span><br></blockquote><blockquote type="cite"><span><tab><space>this is OK</span><br></blockquote><blockquote type="cite"><span><space><space>this is an error</span><br></blockquote><blockquote type="cite"><span><space><tab>this is also an error</span><br></blockquote><blockquote type="cite"><span><tab>under-indenting is an error too</span><br></blockquote><blockquote type="cite"><span><tab><space><space>but you can go nuts after the indentation all you want</span><br></blockquote><blockquote type="cite"><span><tab><space><tab>you do you</span><br></blockquote><blockquote type="cite"><span><tab><space>"""</span><br></blockquote><blockquote type="cite"><span>- The quoted string should *normalize newlines* 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.</span><br></blockquote><blockquote type="cite"><span>// equal to "foo\nfoo\nfoo\nfoo"</span><br></blockquote><blockquote type="cite"><span>"""^J</span><br></blockquote><blockquote type="cite"><span> foo^M^J</span><br></blockquote><blockquote type="cite"><span> foo^J</span><br></blockquote><blockquote type="cite"><span> foo^M</span><br></blockquote><blockquote type="cite"><span> foo^M</span><br></blockquote><blockquote type="cite"><span> """</span><br></blockquote><blockquote type="cite"><span>- It should be clarified that *multiline strings support the same escapes and interpolations* 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.</span><br></blockquote><blockquote type="cite"><span>Thanks John, Brent, and Tyler for the original proposal, and thanks to everyone who participated in the discussion!</span><br></blockquote><blockquote type="cite"><span>-Joe</span><br></blockquote><blockquote type="cite"><span>Review Manager</span><br></blockquote><blockquote type="cite"><span>_______________________________________________</span><br></blockquote><blockquote type="cite"><span>swift-evolution mailing list</span><br></blockquote><blockquote type="cite"><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br></blockquote><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>