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

[Vladimir.S]

On 12.04.2017 22:07, John Holdsworth via swift-evolution wrote:
> Finally.. a new Xcode toolchain 
> <http://johnholdsworth.com/swift-LOCAL-2017-04-12-a-osx.tar.gz> 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.

IMO the rule should be simple: """ is a *marker* of the begin/end of multi-line 
string, not the part of multi-line string itself.
And so there is no question regarding "new line" symbol injection after leading """ 
and before/after trailing """. Each line *between* leading and trailing triple quotes 
- the only lines of multi-string.

And as soon as last line *of text* inside multi-line string has new line, the result 
text also should have it. It is common to have, for example, a text file where last 
line ends with \n symbol, i.e. with "new line" character. It is common to end the 
text in text editor by pressing Enter, so last symbol will be \n. Even in XML/JSON file.
Why we invent a complex/confused rules for multi-line string in Swift code?

I.e.

this:
"""
one
two
"""
should be just the same as "one\ntwo\n"

If one wants some advanced tuning of line ends, he/she can use a backslash, for example
"""
one
two\
"""
should produce "one\ntwo"

Btw, in which situations it is important to remove the trailing \n character from 
*multi-line* string? How is common this use-case? Because I can't think of 
XML/JSON/SQL text, they should not depend on trailing new line symbol.

> 
> 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.
> 
> letlongstring = """\
>              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 
>> <mailto: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
>