> Am 15.04.2017 um 09:24 schrieb Adrian Zubarev via swift-evolution > <[email protected]>: > > 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. -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 ([email protected] > <mailto:[email protected]>) 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 > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
