This is the natural way of text blocks. If you really need a blank line you can add one at the start/end or alternatively use \n.
""" Foo """ // Equals "\nFoo\n" -- Adrian Zubarev Sent with Airmail Am 19. April 2017 um 22:53:07, Vladimir.S via swift-evolution ([email protected]) schrieb: On 19.04.2017 23:03, Joe Groff via swift-evolution wrote: > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md > > Hello Swift Community, > > 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. > > - 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.* > > // Allowed, equal to "foo\nbar" > """ > foo > bar > """ Could you clarify, shouldn't this be equal to "foo\nbar\n" ? I.e. with trailing \n for "bar" line? I didn't find any clarification about the injecting of line-end for last text line(not for the """ delimiter). > > // Not allowed > """foo > bar > """ > > // Not allowed > """ > foo > bar""" > > 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. > > - 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. > > """ > <tab><space>this is OK > <space><space>this is an error > <space><tab>this is also an error > <tab>under-indenting is an error too > <tab><space><space>but you can go nuts after the indentation all you want > <tab><space><tab>you do you > <tab><space>""" > > - 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. > > // equal to "foo\nfoo\nfoo\nfoo" > """^J > foo^M^J > foo^J > foo^M > foo^M > """ > > - 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. > > Thanks John, Brent, and Tyler for the original proposal, and thanks to > everyone who > participated in the discussion! > > -Joe > Review Manager > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
