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 ([email protected]) 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 <[email protected]> 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 ([email protected]) schrieb: On Thu, Apr 13, 2017 at 7:55 PM, Brent Royal-Gordon <[email protected]> wrote: On Apr 13, 2017, at 4:48 PM, Xiaodi Wu <[email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
