Agree. I prefer the new rules over the old, but considering common use cases, stripping the leading and trailing newline makes for a more pleasant experience than not stripping either of them.
I think that is generally worth prioritizing over a simpler algorithm or even accommodating more styles. Moreover, a user who wants a trailing or leading newline merely types an extra one if there is newline stripping, so no use cases are made difficult, only a very common one is made more ergonomic. On Wed, Apr 12, 2017 at 09:52 Thorsten Seitz via swift-evolution < swift-evolution@swift.org> wrote: > > Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org>: > > > > Hey folks, > > > > > > We've revised the proposal again. The main difference: You no longer > need an initial newline to enable indentation stripping, and stripping no > longer removes that newline even if it is present. (Adrian Zubarev and I > believe some others argued for this.) We > > Hmm, not sure if I like these changes. I expect that almost all strings > won't begin with a newline and a majority won’t end with a newline. The new > design would require a leading backslash almost all the time and a trailing > backslash often, which is ugly: > > let mystring = "““\ > text text > text text\ > "““ > > -Thorsten > > > > disagreed with this at first, but it made more sense as we thought about > it more. There are a few things we like about it: > > > > 1. The rules and algorithm are simpler. > > 2. It accommodates more coding styles. > > 3. Every non-escaped newline in the literal now creates a > corresponding newline in the resulting string. > > 4. it's easy to get the old behavior back by backslashing the > leading newline. > > > > Unfortunately, I think this precludes stripping the trailing newline by > default, but I think this is ultimately a simpler and better approach than > the previous draft. > > > > Other changes: > > > > * We realized we needed to make closing delimiter matching a > little more complicated if we wanted to allow one or two adjacent > double-quote characters that were part of the literal's contents. Oops. > > * Tabs aren't actually allowed in ordinary string literals, so we > now explicitly mention that as a difference between the two types. > > * We wrote some tests for the prototype (though they haven't been > updated for this new version yet). > > * There were some other wording changes, particularly in the > indentation stripping rationale, but nothing that affects the actual design. > > > > I understand John is working on a new version of his toolchain so people > can play with the prototype. We hope to have that ready for you all soon. > > > > Let us know what you think of the revisions! > > > > -- > > Brent Royal-Gordon > > Architechies > > > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org > > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution