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

[Adrian Zubarev]

Honestly, 1) is ugly, we don’t want to add a useless new line restriction there, 2) is what I’m pushing in this discussion. 3) is very ugly syntax.



-- 
Adrian Zubarev
Sent with Airmail

Am 14. April 2017 um 14:40:48, Muse M (james.lei65 at gmail.com) schrieb:

In Javascript, this counted as 2 lines which is fine for rendering code, not with HTML5 elements
<pre><code>import Foundation
print("Hello World!")</code></pre>

1st)
In Swift, it's clear to start multi-line on a new line
var code = 
"""
Hello World
"""

If Swift cannot accept the 1st syntax, below 2nd and 3rd syntax could be done better
2nd)
var code = """
Hello World
"""

3) 
var code = {
"""
Hello World
"""
}

I love the 3rd syntax.



On Fri, Apr 14, 2017 at 5:06 PM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
I think I found another argument of not to inject a new line after the last content line, even though it’s not a strong argument.

Consider these two examples:

let string_1 = """foo"""


let string_2 = """
    foo
    """
What’s the intuitive result you’d expect without taking all the long talk from the list into account?

Personally, I’d say string_1 == string_2 is true.

Now you’d might think how about the blank line as an example?

let string_3 = """

    """
However the equivalent for this would be:

let string_4 = """\n"""
Empty string in both variations:

let string_5 = """"""


let string_6 = """
    """


-- 
Adrian Zubarev
Sent with Airmail

Am 14. April 2017 um 03:08:58, Xiaodi Wu (xiaodi.wu at gmail.com) schrieb:

On Thu, Apr 13, 2017 at 7:55 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
On Apr 13, 2017, at 4:48 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

You say "this is the example set by `print`", but I don't think anything else actually *follows* that example. No other I/O operation in Swift behaves this way.

To be more accurate, it's not `print` that specifies this behavior, but rather the standard output stream's implementation of `TextOutputStream.write(_:)`. Swift *explicitly* leaves this choice up to the TextOutputStream-conforming type. That is, the behavior is up to the receiver and not the argument of a call to `TextOutputStream.write(_:)`.

I feel like I must be misunderstanding what you're trying to say here, because I *think* what you're trying to say is that `TextOutputStream.write(_:)` is what decides whether to add the terminator, which is not only totally wrong (see https://github.com/apple/swift/blob/adc54c8a4d13fbebfeb68244bac401ef2528d6d0/stdlib/public/core/Print.swift#L260) but doesn't even make any sense since there's a terminator parameter on `print` but none on `write(_:)`.

Hmm, you're right here with respect to `print()`. It is, however, explicitly contemplated in the documentation for `TextOutputStream.write(_:)` that conforming types can also determine whether or not to append a terminator, and which, inside their implementation of `write`. The example given in the documentation is:

```
struct ASCIILogger: TextOutputStream {
    mutating func write(_ string: String) {
        let ascii = string.unicodeScalars.lazy.map { scalar in
            scalar == "\n"
              ? "\n"
              : scalar.escaped(asASCII: true)
        }
        print(ascii.joined(separator: ""), terminator: "")
    }
}
```



-- 
Brent Royal-Gordon
Architechies



_______________________________________________
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/20170414/36502b90/attachment.html>