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

Adrian Zubarev adrian.zubarev at devandartist.com
Thu Apr 13 08:00:37 CDT 2017


Question: What is the benefit of disabling the indent stripping? I’m not even sure what I should imagine when I read “if the indent stripping is enabled”.

My mental model is simple, the compiler looks for line where the closing tripled delimiter is. Takes all space characters in between the start of the line and the delimiter (there cannot be any other character at all), and makes it as the indent prefix for all content lines s0 to sn. This is simple and does not require an essay of rules to support that.

That said, the indent stripping algorithm is always enabled, except when the indent prefix is an empty string "".

It’s far more simpler to teach the two different types of the multi-line string literal, rather then allowing string content after the starting delimiter and than explaining why the literal does not inject a new line if you happen to write

"""
foo
bar
"""
Instead of:

"""foo
bar
"""
This approach also eliminates the implication of the existence of:

"""
foo
bar"""


-- 
Adrian Zubarev
Sent with Airmail

Am 13. April 2017 um 14:41:45, Brent Royal-Gordon (brent at architechies.com) schrieb:

On Apr 13, 2017, at 5:35 AM, Ricardo Parada via swift-evolution <swift-evolution at swift.org> wrote:

Take a look at Brent's revised proposal.I personally thin it is perfect.  Take a look:

https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md

Well, um, looks like we got scooped. (I was playing with some non-essential wording and trying to test all the examples before I pointed the list at the new version.)

Since requiring a leading backslash went over like a lead balloon, we've revised the proposal one more time. The leading newline is now optional: If indentation stripping is enabled, you can either start typing content on the same line as the delimiter, or you can start on the next line. I resisted this solution for a while because it seems ad-hoc, but ultimately it's the design that preserves the most formatting flexibility for the user, so I think it's the right way to go.

Other than that, there are no changes to the design in this revision, though I've rephrased a few things and added a section about why we strip a leading newline but not a trailing one.

John has also built a new version of the toolchain which matches this behavior. Download it here: http://johnholdsworth.com/swift-LOCAL-2017-04-13-a-osx.tar.gz

Thanks for your feedback!

-- 
Brent Royal-Gordon
Architechies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170413/44ee3a82/attachment.html>


More information about the swift-evolution mailing list