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

[Muse M]

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/099ef92a/attachment.html>