I agree, but unfortunately it’s probably too late now. > On Apr 19, 2017, at 3:11 PM, Martin Waitz via swift-evolution > <[email protected]> wrote: > > Hi, > > I think, it would be more natural to include the last newline. > Multi-line String literals are for multiple lines. > And each line ends in a \n. Otherwise it wouldn’t be a line. > > Having > """ > line 1 > """ > + > """ > line 2 > """ > == > """ > line 1 > line 2 > """ > > makes a lot of sense to me. > > Or do we want to magically add a trailing newline everywhere as we do in > print()? > Better change print to only add the newline when necessary! (e.g. by adding a > new parameter which defaults to „auto“) > > — > Martin > >> Am 19.04.2017 um 23:51 schrieb Adrian Zubarev via swift-evolution >> <[email protected] <mailto:[email protected]>>: >> >> 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] <mailto:[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 >>> > >>> > <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] <mailto:[email protected]> >>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>> > <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> > >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <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
