[swift-evolution] [Review] SE-0168: Multi-Line String Literals
Ricardo Parada
rparada at mac.com
Wed Apr 12 13:29:55 CDT 2017
Okay, so maybe we should not strip the trailing newline.
The xml concatenation example in Brent's revised proposal assumes the literal includes a trailing newline.
Also, if you do this in Swift:
print("Line1\n")
print("Line 2")
It seems to strip trailing newlines. So the above actually outputs this with no empty line in between them:
Line 1
Line 2
Conclusion: I think it is best to include the trailing newline. :-)
> On Apr 12, 2017, at 1:52 PM, Adrian Zubarev <adrian.zubarev at devandartist.com> wrote:
>
> Actually this would be inconsistent. The lines in between the delimiters should always add an implicit new line if not told otherwise with a backslash. If that wouldn’t be the case than you won’t have any precision in the last line you have there.
>
> Assume you want to concatenate this string:
>
> foo
> bar baz
> To do so you’d need extra spaces in your " baz" string, because of the inconsistency. However the constant version I’m suggesting is more precise.
>
> let myString = """
> foo
> bar \
> """
>
> print(myString + "baz")
> The last implicit new line which one would need to escape is a model artifact, but it’s consistent that way.
>
> The extra new line one would ever need to add manually would be only at the top of a multi-line string.
>
> // v1:
>
> """
>
> foo
> bar\
> """
>
> // v2:
> """
> \n\
> foo
> bar\
> """
>
> // v3:
> """
> \nfoo
> bar\
> """
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 12. April 2017 um 19:41:14, Ricardo Parada via swift-evolution (swift-evolution at swift.org <mailto:swift-evolution at swift.org>) schrieb:
>
>> Hi all,
>>
>> I agree as well, I think we should make optimize for the most common case of multi-line strings. A rule that says strip the first leading newline as well as the trailing newline. So it's almost back to where Brent started with the addition of removing the trailing newline.
>>
>> Borrowing Adrian's example, I could just have 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>
>> """
>> If somebody wants the last line to include a newline at the end, they can just add a \n at the end or an empty line.
>>
>> So if I do this:
>> print(myReallyLongXMLConstantName)
>> print("Text right below")
>> It would output this:
>>
>> <?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>
>> Test right below
>>
>> Without removing the trailing newline then it would print like this:
>>
>> <?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>
>>
>> Test right below
>>
>>
>>
>>
>>> On Apr 12, 2017, at 12:48 PM, 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.
>>> On Wed, Apr 12, 2017 at 09:52 Thorsten Seitz via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> > Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>>> >
>>> > 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
>>>
>>> Hmm, not sure if I like these changes. I expect that almost all strings won't begin with a newline and a majority won’t end with a newline. The new design would require a leading backslash almost all the time and a trailing backslash often, which is ugly:
>>>
>>> let mystring = "““\
>>> text text
>>> text text\
>>> "““
>>>
>>> -Thorsten
>>>
>>>
>>> > 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 <mailto:swift-evolution at swift.org>
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> 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/aacf2b96/attachment.html>
More information about the swift-evolution
mailing list