We had a very full debate about which way was superior during review; it was proposed to behave one way and the core team decided on the other. We have to let settled decisions be settled: that's the only way Swift Evolution will continue to work.
On Wed, Apr 19, 2017 at 5:15 PM, Kevin Nattinger via swift-evolution < [email protected]> wrote: > 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]>: > > 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 > > > _______________________________________________ > 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
