[swift-evolution] multi-line string literals.

[Adrian Zubarev]

Hi Tyler,

You’re a bit late indeed. The proposal got accepted with some modifications.

No single line expression (for now).
The last string content line does not add an implicit new line to the resulting string.
Text is always in lines (content lines) between the delimiter lines, but never directly after or before the delimiters.
The indent and stripping is solved by calculating the indent prefix for the closing delimiter, mismatch in content lines results in an error.
Trailing backslash is not included and can be proposed as an additional feature later.
It’s not yet clear if the final version will warn about trailing whitespaces (I’d prefer that). Otherwise the following example could have 1000 characters and no one will ever guess it correctly.
"""
Foo<space><space>…<space>
"""
That last issue can be solved nicely by a trailing backslash as well, because it makes the trailing whitespace boundary visible like the closing delimiter makes it visible for leading whitespaces. And at the same time it would allow us to escape the new line injection when it’s desired.

The concatenation is a no go for my issue. I always used small strings to showcase the problem, but in reality the string I was speaking about could be very long similar to this example: https://gist.github.com/DevAndArtist/345ce0920de62349c1079e18201aea94

That’s why I pursue the addition of the trailing backslash.



-- 
Adrian Zubarev
Sent with Airmail

Am 21. April 2017 um 11:17:19, Tyler Cloutier (cloutiertyler at aol.com) schrieb:

I am very much a fan of this type of thing.

It's very clear that new line are included in the string. Leading white space is explicit. It is easy to align. It's easy to copy and paste. And there isn't excessive escaping.

On Apr 3, 2017, at 7:00 AM, Ricardo Parada via swift-evolution <swift-evolution at swift.org> wrote:

What is the purpose of that backslash?  It does not feel like an improvement. 

I think we should focus on:

1. Looking pretty
2. Allow unescaped quote, double quote as well single/double apostrophe characters 
3. Allow interpolation 
4. No need to add the \n character for each line
5. It should have a continuation character
6. Keep it simple

Something like this:

let xml = M"<?xml version="1.0"?>
           "<catalog>
           " <book id="bk101" empty="">
           "     <author>\(author)</author>
           " </book>
           "</catalog>
Or maybe this:

let xml = """<?xml version="1.0"?>
            "<catalog>
            " <book id="bk101" empty="">
            "     <author>\(author)</author>
            " </book>
            "</catalog>
In the first example the multiline literal is started with M".  In the second example it starts with three double quotes """.  I really have no preference.  In both examples there is no need to have a \ or \n at the end of the line.

You can have quote characters in the string, including double quotes as shown by empty="".  You can have interpolation, i.e. \(author). 

You have a continuation character which helps as a visual guide and as a marker for the beginning of each line.

The multi string literal ends when there are no more continuation characters.



On Apr 3, 2017, at 3:01 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:

Hello Swift community,

on Github there is a PR for this proposal, but I couldn’t find any up to date thread, so I’m going to start by replying to the last message I found, without the last content.

I really like where this proposal is going, and my personal preference are *continuation quotes*. However the proposed solution is still not perfect enough for me, because it still lacks of precise control about the trailing space characters in each line of a multi-line string.

Proposed version looks like this:

let xml = "<?xml version=\"1.0\"?>
    "<catalog>
    "    <book id=\"bk101\" empty=\"\">
    "        <author>\(author)</author>
    "        <title>XML Developer's Guide</title>
    "        <genre>Computer</genre>
    "        <price>44.95</price>
    "        <publish_date>2000-10-01</publish_date>
    "        <description>An in-depth look at creating applications with XML.</description>
    "    </book>
    "</catalog>
    ""
I would like to pitch an enhancement to fix the last tiny part by adding the escaping character ‘' to the end of each line from 1 to (n - 1) of the n-lined string. This is similar to what Javascript allows us to do, except that we also have precise control about the leading space character through ’"’.

The proposed version will become this:

let xml = "<?xml version=\"1.0\"?>\   
    "<catalog>\ // If you need you can comment here
    "    <book id=\"bk101\" empty=\"\">\
    "        <author>\(author)</author>\
    "        <title>XML Developer's Guide</title>\
    "        <genre>Computer</genre>\
    "        <price>44.95</price>\
    "        <publish_date>2000-10-01</publish_date>\
    "        <description>An in-depth look at creating applications with XML.</description>\
    "    </book>\
    "</catalog>\
    ""
Here is another example:

let multilineString: String = "123__456__\ // indicates there is another part of the string on the next line
                              "__789_____\ // aways starts with `"` and ends with either `\` or `"`
                              "_____0_" // precise control about pre- and post-space-characters

let otherString = "\(someInstance)\ /* only comments are allowed in between */ "text \(someOtherInstance) text"
This is simply continuation quotes combined with backslash concatenation.





-- 
Adrian Zubarev
Sent with Airmail


_______________________________________________
swift-evolution mailing list
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/20170421/79bd7c5e/attachment.html>