I don't think the intent of multi-line string literals is to replace files or 
templating libraries. I use those all the time and are superior. 

I think it would be handy and make it more pleasant to use for simple cases. 

Who has not run into a little multi-line literal in your code where you 
concatenate the pieces using +, add \n at the end of each line and have to 
escape quotes?


> On May 12, 2016, at 12:36 PM, Leonardo Pessoa <m...@lmpessoa.com> wrote:
> 
> I'm not in favour of multiline strings. I believe such strings should be 
> stored in plain files and loaded as needed. It makes both the code and the 
> string cleaner to read and maintain. I've had experiences with many languages 
> that offer that resource and I could see what your code can become in terms 
> of maintainability when you have such feature on the language.
> 
> -1 from me.
> 
> - Leonardo
> 
>> On 12 May 2016 at 01:05, Eduardo Mourey Lopez Ne via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> Something like this might work
>> 
>> //string ends on the first line that doesnt start with a "
>> foo( @"<?xml version="1.0"?>
>>        "<catalog>
>>        "   <book id="bk101" empty="">
>>        "       <author>\(author)</author>
>>        "       <title>XML Developer's Guide</title>
>>        "       <genre>Computer</genre>
>>        "       <price>44.95</price>
>>        "       <publish_date>2000-10-01</publish_date>
>>        "       <description>An in-depth look at creating applications with   
>>  XML.</description>
>>        "   </book>
>>        "</catalog>\n
>>     )
>> 
>> //additionally using a +" could be used to indicate a line break
>> foo( @"<?xml version="1.0"?>
>>       +"<catalog>
>>       +"   <book id="bk101" empty="">
>>       +"       <author>\(author)</author>
>>       +"       <title>XML Developer's Guide</title>
>>       +"       <genre>Computer</genre>
>>       +"       <price>44.95</price>
>>       +"       <publish_date>2000-10-01</publish_date>
>>       +"       <description>An in-depth look at creating applications with   
>>  XML.</description>
>>       +"   </book>
>>       +"</catalog>\n
>>     )
>> 
>>> On May 11, 2016, at 9:48 PM, Ricardo Parada via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> 
>>> 
>>> On May 11, 2016, at 2:34 PM, Vladimir.S <sva...@gmail.com> wrote:
>>> 
>>>>> For example:
>>>>> 
>>>>> 
>>>>> letsourceCode =@“NSString *firstName = @“John”;
>>>>>                 "NSString *lastName = @“Doe”;
>>>>>                 “NSString *fullName = [NSString stringWithFormat: @“%@
>>>>> %@“, firstName, lastName];"@
>>>>> 
>>>>> The one that would be a bit of a problem is the closing delimiter,
>>>> 
>>>> Yes.. this is why I asked about `"@` - closing delimiter
>>>> so.. what is the solution in your case ?
>>> 
>>> Hi Vladimir,
>>> 
>>> I don't really have a solution. Perhaps escaping the closing delimiter like 
>>> this \"@
>>> 
>>> It is not pretty but I can't think of anything else. I imagine the other 
>>> alternatives, i.e.   the triple quote `"""` and the quote plus underscore 
>>> `"_ `  have the same problem. 
>>> 
>>> If we make the continuation quote required then we don't need a closing 
>>> delimiter. That would solve the problem. But I've seen several people say 
>>> they don't like the continuation quote because they want to be able to 
>>> paste text and not have to worry much about formatting it afterwards. 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
              • Re: ... John Holdsworth via swift-evolution
              • Re: ... Ricardo Parada via swift-evolution
              • Re: ... Vladimir.S via swift-evolution
              • Re: ... Ricardo Parada via swift-evolution
              • Re: ... Vladimir.S via swift-evolution
              • Re: ... Ricardo Parada via swift-evolution
              • Re: ... Vladimir.S via swift-evolution
              • Re: ... Ricardo Parada via swift-evolution
              • Re: ... Eduardo Mourey Lopez Ne via swift-evolution
              • Re: ... Leonardo Pessoa via swift-evolution
              • Re: ... Ricardo Parada via swift-evolution
              • Re: ... Leonardo Pessoa via swift-evolution
              • Re: ... Cole Campbell via swift-evolution
              • Re: ... L Mihalkovic via swift-evolution
              • Re: ... Ricardo Parada via swift-evolution
              • Re: ... Brent Royal-Gordon via swift-evolution
              • Re: ... Sean Heber via swift-evolution
              • Re: ... Ricardo Parada via swift-evolution
              • Re: ... Michael Peternell via swift-evolution
  • Re: [swift-evolution] multi-li... Uli Kusterer via swift-evolution

Reply via email to