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

[Adrian Zubarev]

Sorry for spamming the list with small correction mails. The forum cannot come faster so I could edit my typos.

Anyways I meant that the example literal won’t work correctly.



-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 23:10:39, Adrian Zubarev (adrian.zubarev at devandartist.com) schrieb:

If I understand #2 correctly than it work for this literal.

let x = """↵
abc↵
"""
Iff we only remove the top new line when the below part is indented than the literal from above would produce "\nabc\n", which I wouldn’t expect.

Compared to:

let x = """↵
··abc↵
··"""
In the multi-lined version of that literal, the starting delimiter does only one job: “look I’m gonna provide a multi-line string in between me and the closing delimiter”. That’s it’s only job. (Not yet officially proposed, nor it’s in the current toolchain.)

The closing delimiter however covers the leading precision and the indent of the current literal. However this is partly visible for a literal that fully fits onto your screen. (That’s already included in current toolchain.)

The trailing precision is covered by the backslash (because it’s visible and intuitive for the developer), otherwise all whitespace characters are stripped at the end and a new line character is implicitly added to that line. (Not handled in the current toolchain.)



-- 
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 21:08:19, John Holdsworth via swift-evolution (swift-evolution at swift.org) schrieb:

Finally.. a new Xcode toolchain is available largely in sync with the proposal as is.
(You need to restart Xcode after selecting the toolchain to restart SourceKit)

I personally am undecided whether to remove the first line if it is empty. The new
rules are more consistent but somehow less practical. A blank initial line is almost
never what a user would want and I would tend towards removing it automatically.
This is almost what a user would it expect it to do.

I’m less sure the same applies to the trailing newline. If this is a syntax for
multi-line strings, I'd argue that they should normally be complete lines -
particularly since the final newline can so easily be escaped.

        let longstring = """\
            Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod \
            tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, \
            quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.\
            """

        print( """\
            Usage: myapp <options>
            
            Run myapp to do mything
            
            Options:
            -myoption - an option
            """ )

(An explicit “\n" in the string should never be stripped btw)

Can we have a straw poll for the three alternatives:

1) Proposal as it stands  - no magic removal of leading/training blank lines.
2) Removal of a leading blank line when indent stripping is being applied.
3) Removal of leading blank line and trailing newline when indent stripping is being applied.

My vote is for the pragmatic path: 2)

(The main intent of this revision was actually removing the link between how the
string started and whether indent stripping was applied which was unnecessary.)

On 12 Apr 2017, at 17:48, 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.

_______________________________________________
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/025e4203/attachment.html>