> [...] a single newline is always stripped after the opening delimiter and > before the closing one. [...]
Regards Anders > On 20 Apr 2017, at 04:52, Vladimir.S via swift-evolution > <[email protected]> wrote: > >> 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
