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

Matthew Johnson matthew at anandabits.com
Wed Apr 12 08:47:04 CDT 2017

> On Apr 12, 2017, at 8:40 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 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!

I haven’t formally reviewed this proposal but have been following the thread.  I generally like this proposal quite a bit.  I have used multi-line strings quite a bit in other languages and this proposal does a really nice job of avoiding the small annoyances I’ve encountered.  Thanks for your hard work!  +1 

> -- 
> Brent Royal-Gordon
> Architechies
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

More information about the swift-evolution mailing list