[swift-evolution] [Review] SE-0168: Multi-Line String Literals
Ricardo Parada
rparada at mac.com
Sat Apr 15 09:46:05 CDT 2017
Reply inline.
On Apr 15, 2017, at 8:48 AM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>
>> Am 15.04.2017 um 09:24 schrieb Adrian Zubarev via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>>
>> I disagree, the examples you have provided are more complicated than you might think they are. Before explaining why, I’m going to make things clear about the ‘two modes’ of the multi-line string literal.
>>
>> I’m not sure where this wording has popped out first and I’m not going to search for it. IIRC Xiaodi Wu has pitched the idea before me to ban text after the starting delimiter. After Brents reply where I questioned the stripping algorithm for literals like the following one:
>>
>> """abc
>> def"""
>> I was convinced that we should not put any text before the closing delimiter to make the algorithm easier to understand. Combined with the mentioned pitch by Xiaodi Wu, I suggested to fully ban three options of the (revisited) proposed literal.
>>
>> let v1 = """abc
>> def"""
>>
>> let v2 = """abc
>> def
>> """
>>
>> let v3 = """
>> abc
>> def"""
>> This allows us to craft a far simpler model, which would be easy to learn and teach. Yet we haven’t removed or added new ‘modes’ from/to the model itself. I don’t think it was ever intended for v1 to add an implicit trailing new line after "def"?! The first small examples support my assumption here:
>>
>> https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md#simple-multi-line-string <https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md#simple-multi-line-string>
>> """Hello\↵
>> world!"""
>>
>>
>> // Result:
>> "Helloworld!"
>> What we did so far, was only to disallow a few options on how we should not write multi-line string literals in Swift. We did not add any differentiation between the option of ‘single-lined’ tripled string literal and the one that contains more than a single content line in it. Simply as that v3 was tweaked to have an explicit ↵ at the end of its last content line to follow the rules, but the resulting string should remain the same.
>>
>> let from_v3_to_v4 = """
>> abc
>> def
>> """
>> Unfortunately the revisited proposal does not contain any examples like
>>
>> let str_1 = """
>> abc"""
>>
>> let str_2 = """
>> abc
>> """
>> to strengthen my argumentation even further. str_1 is an example where you could think that you’ve simply rotated the way how you’d write the literal from a single line into two lines, which as currently proposed would be totally valid and produce the "abc" string. str_2 is the same string as str_1 but with adopted delimiter restrictions.
>>
>> Long story short, there are no different modes the literal provides for you. You cannot write (visually) multiple lines in a single content line right (except with \n, but that’s not what I mean here). Think about it, don’t let you fool yourself by my wording. But you should be able to write a single line in a multi line content way and still have the same result as before. This rule only applies to the last content line, but since a single line is automatically the last content line the next two literals produces the exact same string.
>>
>> let str_3 = """abc"""
>>
>> let str_4 = """
>> abc
>> """
>>
>> str_3 == str_4 // => true
>> str_3 == "abc" // => true
>> Now it’s time to solve the puzzle in your example. The correct result should be as follows:
>>
>> (a + b) == """
>> This is line one
>> This is line twoThis is line three
>> This is line four
>> """
>>
>> // Or more precise
>> (a + b) == "This is line one\nThis is line twoThis is line three\nThis is line four“
>
> I disagree and think BJ Homer is right: the multiline variant contains *lines* which all end with a newline. That is a very simple mental model.
>
> I do agree that the mixed modes (v1, v2, v3) should be banned.
Hi Thorsten, I think v2 would allow you to pick an alternate style to define your multiline string literal. For example, take a look at the xml string literal defined in two different ways under the Indentation Stripping section in Brent's proposal here:
https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md <https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md>
Here is another example:
case .isExprSameType(let from, let to):
return """checking a value with optional type \(from) \
against dynamic type \(to) \
succeeds whenever the value is non-'nil'; \
did you mean to use '!= nil'?\
"""
I personally do not find this style confusing at all. The first line has its text begin immediately after the opening delimiter so there is no indentation that needs to be stripped from it. That is really all there is to it, IMO. Only lines two and beyond have their indentation stripped as specified by the closing delimiter. And of course, we could also use the other style:
case .isExprSameType(let from, let to):
return """
checking a value with optional type \(from) \
against dynamic type \(to) \
succeeds whenever the value is non-'nil'; \
did you mean to use '!= nil'?\
"""
We get a choice to pick the one that we like better.
There is also an Xcode toolchain that was put together and you can try this out:
http://johnholdsworth.com/swift-LOCAL-2017-04-13-a-osx.tar.gz <http://johnholdsworth.com/swift-LOCAL-2017-04-13-a-osx.tar.gz>
> -Thorsten
>
>
>
>>
>> One more thing to add to the story that there really are no two different modes, but only two options of writing a single line as a consequence of the whole multi-line string literal.
>>
>> Without having the multi-string literal, take two text files which would each contain the following text snippets, instantiate a String from each of the files and concatenate the strings.
>>
>> First text file A:
>>
>> Foo
>> Bar
>> [this is a blank line]
>> First text file B:
>>
>> Foo
>> Bar
>> What’s the result you’d expect for a + b?
>>
>> It’s trivial right?
>>
>> Foo
>> Bar
>> [this is a blank line]
>> Foo
>> Bar
>> The exact same behavior cannot be translated into the proposed multi-line string literal because of the implicit trailing new line, but it could be when we adopt the behavior I was described above and leave the last content line without any injection.
>>
>> With the suggested way, you can also simply copy-paste the whole content of the files inclusion all blank lines and expect the same behavior for the concatenation.
>>
>> let a = """
>> Foo
>> Bar
>> [this is a blank line]
>> """
>>
>> let b = """
>> Foo
>> Bar
>> """
>>
>> a + b == "Foo\nBar\nFoo\Bar"
>> And just another side note. The example from the revisited proposal does look fine if anyone would decide to write it like this:
>>
>> let myXMLString = """
>> <a href="\(url)" id="link\(i)" class="link">
>> """
>> Especially when there would be any leading and trailing quotes:
>>
>> let myString = """
>> "Hello·world!"
>> """
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 14. April 2017 um 23:35:29, BJ Homer (bjhomer at gmail.com <mailto:bjhomer at gmail.com>) schrieb:
>>
>>> let a = """
>>> This is line one
>>> This is line two"
>>> """
>>>
>>> let b = """
>>> This is line three
>>> This is line four
>>> """
>>>
>>> (a + b) == """
>>> This is line one
>>> This is line two
>>> This is line three
>>> This is line four
>>> """
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170415/d90a03a8/attachment.html>
More information about the swift-evolution
mailing list