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

[Thorsten Seitz]

> Am 21.04.2017 um 15:45 schrieb David Hart via swift-evolution <swift-evolution at swift.org>:
> 
> 
>> On 21 Apr 2017, at 11:32, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Dear Xiaodi Wu, why do you always have to be offensive in a way of questioning every single word another person says and not letting others to have their own opinion?! I do not want to have a discussion with you that will and up you asking me why is the banana crooked. I expect a focused and a constructive discussion if not mentioned otherwise.
>> 
>> My expectation from the model of the multi-lined string literal might be different from yours and you’ll have to bear with that, because I’ve got my own opinion. If you’d like me to see things differently, try to convince me instead of being unfocused and questioning every single word I’m saying. That won’t lead use to anywhere.
>> 
> Hi Adrian. For what it's worth, I did not detect any offense in Xiaodi’s questions. I think he was just asking questions to point parts of your opinion which he did not understand or was missing some reasoning.
>> I expect the model to solve two major problems. The first one is already solved by the accepted version. The second one is the ability to escape new lines when needed (notice, I do not want to escape them all the time, but only where it’s desired). The accepted version adds more possibilities to the language and will definitely fix a lot of pain with string literals some developer had. I’m happy to see that. However from my personal standpoint, I do not write any code generators created from string literals as it was a heavily overused example in the proposal and during the discussion. I often need the ability to wrap very long strings into multiple lines for readability, but keep the result string intact. In my last response I showed a sample on how it might look like and that it’s really painful to read such a string on Git, because it does not provide any soft-wrapping like other tools might do. That is why I keep saying that the multi-line string literal should not rely on editors to solve that problem. Otherwise the bare existence of the such literal could be questioned and we could fully fall back to editor features like soft-wrapping or let the editor also wrap strings when it finds a new line character \n to mimic the proposed behavior. I also do not like the argument of using string concatenation to solve my particular issue, because the strings are very long and it quickly becomes were tedious. Furthermore, the multi-line string literal should not be only reserved for solving the problems you’ve mentioned. A trailing backslash does not add any complexity, and you personally don’t need that feature it does not mean that others won’t need it. It’s an additional feature which is lightweight and which won’t harm the copy-paste phenomenon most of you wanted. If you really think it adds complexity than you should also justify your thoughts to convince your conversation partner. 
>> 
>> IMHO ‘complexity’ creates ‘flexibility’. If we’d only had one access modifier in Swift the model would be really simple but not flexible. Not that we have a bunch of them the model become complex but on the other hand it also become way more flexible.
>> 
> But for what its worth, I agree with Adrian. Let me try to expose the use-case the proposal is not addressing:
> 
> A group of people (me included) don’t wrap lines in their editor (by choice) but make sure that lines of code don’t extend over a certain limit (80, 100, 120, whatever). This allows us to keep code readable and control the wrapping behaviour by manually applying it.
> 
> For those people, writing long prose which extends over our limit (like is the case in some error/assert/precondition messages), we won’t be able to use the multi-line string proposal and we will have to stay with string concatenation:
> 
> Taking the following piece of code:
> 
> func myFunction() {
>     assert(aVariable > 10 && anotherVariable < 50, “Variables `aVariable` and `anotherVariable` are outside their expected range. Please check that your are not calling this function around midnight”)
> }
> 
> I currently write it using string concatenation:
> 
> fun myFunction() {
>     assert(aVariable > 10 && anotherVariable < 50, "Variables `aVariable` and `anotherVariable` " +
>         "are outside their expected range. Please check that your are not calling this function " +
>         "around midnight")
> }
> 
> But writing it using the multi-line string syntax:
> 
> fun myFunction() {
>     assert(aVariable > 10 && anotherVariable < 50, """Variables `aVariable` and `anotherVariable` 
> 	are outside their expected range. Please check  that your are not calling this function 
> 	around midnight
>         """)
> }
> 
> will inject unwanted newlines. I think what we would like to be able to do is:
> 
> fun myFunction() {
>     assert(aVariable > 10 && anotherVariable < 50, """Variables `aVariable` and `anotherVariable` \
> 	are outside their expected range. Please check  that your are not calling this function \
> 	around midnight
>         """)
> }
> 
> Notice how the space at the end of the line is also quite obvious now.

I totally agree with Adrian and David. Being able to hard wrap long strings without newlines and without breaking indentation due to softwrapping is important while keeping trailing spaces visible (like they are in a normal string). All this is fulfilled by the trailing backslash.

-Thorsten

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170421/2bdf9571/attachment.html>