I think that there's nothing wrong with two "tools" for the same task in this case. Multiline strings look better in the code and are easier to read and can serve many purposes. By reading different texts from swift dev team I feel like this is something the language was designed with in mind. They're also easier to type and it needn't neccessarily be a string presented to the user.
Lets say I want a simple json literal for testing purposes - reading from a file takes much more effort comparing to inserting it directly in the code. Taking out every new line character makes it hard to read, and inserting quotes and pluses every line both needs extra effort and also decreases readability. Adding it as a multiline string would make a perfect solution for this to me. There are so many other cases where this could be useful too. I like how python has the """ and I think this would be a good direction to go, although this is true that python uses indentation in a different way, so I think backslashes at the end of each line would be a nice idea - this is still better than concatenating each line with " and +, and would have the least readability impact. Also, it could be treated as a literal and be evaluated at compile time. > I just checked with -O and without and was surprised to find that `let x = > "abc" + "def" + "ghi"` wasn't collapsed into a single string literal > "abcdefghi" in the generated assembly code. Maybe it's more difficult than it > is in some other languages because of operator overloads and different kinds > of text literals (strings, extended grapheme clusters, Unicode scalars)? > > Regardless of the reasons, a separate syntax isn't the right way to achieve > this optimization―the compiler should just do it automatically. Like Ricardo, > "multi-line string literals" should be reserved for string literals that > include the newline characters that are used to break them up in source. The > idea of supporting something like the Python example above just provides two > ways to do the same thing, which I don't think we really need. > > >> On Mon, Apr 3, 2017 at 8:18 AM Ricardo Parada via swift-evolution >> <[email protected]> wrote: >> >> I would think that the concatenation would get resolved at runtime, unless >> the compiler gets smart about it. But either way I do not see it as a >> problem. The reason is that I don't remember ever worrying about the >> performance of concatenating a few lines of text. :-) >> >> Thanks >> >> >>> On Apr 3, 2017, at 11:13 AM, Adrian Zubarev >>> <[email protected]> wrote: >>> >>> To me a literal a single entity which is solved at compile time. The >>> concatenation is however resolved at runtime if I’m not mistaken here (it >>> might be optimized at compile time but I still would expect a function >>> executed a couple of times at runtime). >>> >>> Please correct me if I’m wrong here. >>> >>> >>> >>> >>> -- >>> Adrian Zubarev >>> Sent with Airmail >>> >>> Am 3. April 2017 um 17:10:36, Ricardo Parada ([email protected]) schrieb: >>> >>>> How is that better than this? >>>> >>>> template = "This is the first line.\n" + >>>> "This is the second line.\n" + >>>> "This is the third line." >>>> >>>>> On Apr 3, 2017, at 10:42 AM, Ricardo Parada via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> It look prettier without the \n >>>>> >>>>> It's not laziness. >>>>> >>>>> I want my code to look pretty. >>>>> >>>>> >>>>>> On Apr 3, 2017, at 10:40 AM, Adrian Zubarev >>>>>> <[email protected]> wrote: >>>>>> >>>>>> What I was trying to say is that by automatically adding a new line >>>>>> character does not provide any benefit except of being lazy to type \n. >>>>>> >>>>>> // In your model this would be equivalent >>>>>> let s1 = "\n\n\n" >>>>>> let s2 = """ >>>>>> " // However in my model this is an empty string and should be banned >>>>>> " >>>>>> """ // That's also an empty string, but it that case it indicates >>>>>> the end of the multi lined string >>>>>> I dislike the tradeoff of precision for laziness. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Adrian Zubarev >>>>>> Sent with Airmail >>>>>> >>>>>> Am 3. April 2017 um 16:29:44, Ricardo Parada ([email protected]) schrieb: >>>>>> >>>>>>> By the way, the multi-line string should allow \n\n, or as many as you >>>>>>> may want to throw in there. I don't see a problem with that. >>>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
