[swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Xiaodi Wu]

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 at swift.org> wrote:

> > Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution <
> swift-evolution at 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 at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170412/eb8804a2/attachment.html>