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

Adrian Zubarev adrian.zubarev at devandartist.com
Fri Apr 14 12:21:37 CDT 2017

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>

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
var code = """
Hello World

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 = """
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

swift-evolution mailing list
swift-evolution at swift.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170414/36502b90/attachment.html>

More information about the swift-evolution mailing list