[swift-evolution] [Review] SE-0168: Multi-Line String Literals
Jarod Long
swift at lng.la
Wed Apr 12 13:58:36 CDT 2017
This is the most logical newline stripping behavior in my opinion. It's very easy to think about -- all the lines in-between the triple quotes are the contents of the string. Leading and trailing newlines are easily added if desired by adding extra lines.
To support that model, I also agree with the suggestion that we shouldn't allow multiline string contents on the same line as the opening or closing delimiters. They are multiline strings after all, so I don't see much value in supporting that.
On a separate note, I'd like to bring up the de-indentation behavior I described earlier again. I still feel that having the position of the closing delimiter determine how much whitespace is de-indented is not very natural or intuitive, since I don't think there is any precedent in standard Swift styling to indent a closing delimiter to the same level as its content. Stripping the most common whitespace possible from each line seems to be a much more intuitive and flexible solution in terms of formatting, and it's still compatible with the proposed formatting if that's anyone's preference.
The only functional limitation that I see is that if you can't have leading whitespace in the interpreted string if you actually want that. That doesn't seem like a very important use case to me, but if we think it is important, it could be supported by something like having a backslash in the leading whitespace at the location where it should be preserved from.
If we're set on the proposed behavior, have we considered what happens if the closing delimiter goes beyond the non-whitespace content of the string?
let string = """
aa
bb
cc
"""
Does it strip the non-whitespace characters? Does it strip up to the non-whitespace characters? Does it generate an error?
Jarod
On Apr 12, 2017, 10:41 -0700, Ricardo Parada via swift-evolution <swift-evolution at swift.org>, wrote:
> Hi all,
>
> I agree as well, I think we should make optimize for the most common case of multi-line strings. A rule that says strip the first leading newline as well as the trailing newline. So it's almost back to where Brent started with the addition of removing the trailing newline.
>
> Borrowing Adrian's example, I could just have this:
>
>
> let myReallyLongXMLConstantName = """
> <?xml version="1.0"?>
> <catalog>
> <book id="bk101" empty="">
> <author>John Doe</author>
> <title>XML Developer's Guide</title>
> <genre>Computer</genre>
> <price>44.95</price>
> </book>
> </catalog>
> """
> If somebody wants the last line to include a newline at the end, they can just add a \n at the end or an empty line.
>
> So if I do this:
>
> print(myReallyLongXMLConstantName)
> print("Text right below")
> It would output this:
>
> <?xml version="1.0"?>
> <catalog>
> <book id="bk101" empty="">
> <author>John Doe</author>
> <title>XML Developer's Guide</title>
> <genre>Computer</genre>
> <price>44.95</price>
> </book>
> </catalog>
> Test right below
>
> Without removing the trailing newline then it would print like this:
>
> <?xml version="1.0"?>
> <catalog>
> <book id="bk101" empty="">
> <author>John Doe</author>
> <title>XML Developer's Guide</title>
> <genre>Computer</genre>
> <price>44.95</price>
> </book>
> </catalog>
>
> Test right below
>
>
>
>
> > On Apr 12, 2017, at 12:48 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> >
> > 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
> > _______________________________________________
> > 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/dd9c1283/attachment.html>
More information about the swift-evolution
mailing list