[swift-evolution] [Review] SE-0168: Multi-Line String Literals
Adrian Zubarev
adrian.zubarev at devandartist.com
Wed Apr 12 09:19:42 CDT 2017
I messed up the indent in the example, where is the corrected version:
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>\
"""
--
Adrian Zubarev
Sent with Airmail
Am 12. April 2017 um 16:05:59, Adrian Zubarev (adrian.zubarev at devandartist.com) schrieb:
Hi Brent, thank you for the hard work and the new revision. However I still would love to hear your opinion if we should drop the support for these kind of options:
"""Hello↵
world!"""
"""↵
Hello↵
world!"""
"""Hello↵
world!
"""
I tend to agree that it’s much simpler to only support a single line version and a version where the actual string is in between the delimiter lines but not directly after or before them. Personally I don’t think you would always want to indent your multi-line string that far to the right side.
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>\
"""
Instead it’s easer and readable enough to write it like 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>\
"""
The starting delimiter does not produce a new line, only each line in between does if not explicitly prevented with a backslash. If you’d wanted to add a new line at the top, you just simply add one or \n below the starting delimiter.
--
Adrian Zubarev
Sent with Airmail
Am 12. April 2017 um 15:40:26, Brent Royal-Gordon via swift-evolution (swift-evolution at swift.org) schrieb:
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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170412/f732be95/attachment.html>
More information about the swift-evolution
mailing list