<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><span style="font-size: 13.800000190734863px;" class="">Hi.</span></div><div class=""><span style="font-size: 13.800000190734863px;" class=""><br class=""></span></div><div class="">The solutions discussed so far have the following disadvantages:</div><div class="">&nbsp; - They need a specific delimiter token, which cannot be used in the text itself.</div><div class="">&nbsp; - The data cannot be used as-is, escape \ characters are needed.</div><div class="">&nbsp; - Imho, they are somewhat complicated.&nbsp;</div><div class=""><br class=""></div><div class="">In my emails previously submitted I came up with a "data line” concept,</div><div class="">a very simple solution, which tackles these disadvantages and is</div><div class="">very easy to use and understand!</div><div class=""><br class=""></div><div class="">Did you actually read it?&nbsp;</div><div class="">I now quote the primary description hereunder again, in case you’ve missed it,</div><div class="">imaginable, because there is a lot of text flying around.</div><div class=""><br class=""></div><div class=""><div class="">Additionally, the following improvements have developed in my thinking:&nbsp;</div></div><div class=""><br class=""></div><div class="">In the mean time I consider using two tokens &nbsp; \\ and \@: &nbsp;</div><div class="">&nbsp; &nbsp; <a href="smb://…data…data…data…data" class="">\\…data…data…data…data</a>………….. &nbsp; accepts data and converts \n \t etc.</div><div class="">or data lines starting with:&nbsp;</div><div class="">&nbsp; &nbsp; \@…data…data…data…data… .……. &nbsp;accepts data as-is, without conversion and&nbsp;</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;respects the linefeeds of the source-file.</div><div class=""><br class=""></div><div class="">the // and /@ tokens do not have to start at the beginning of a line,&nbsp;</div><div class="">are allowed further to the right as long as there are only space(s) to the</div><div class="">left of it.</div><div class=""><br class=""></div><div class="">let music =</div><div class=""><a href="smb://when" class="">\\when</a> Doves Cry\nBy Prince and</div><div class="">\\ The Revolution\nWhat music</div><div class="">\\ &nbsp;can be\t\t\t\tIt is \”Magic\” really.</div><div class="">&nbsp;</div><div class="">If you do or don’t like this solution&nbsp;</div><div class="">-apart from cosmetic viewpoints-</div><div class="">please tell me why. so I can improve it,</div><div class="">or try to come back with something better if i can.</div><div class=""><br class=""></div><div class="">let epilogue =</div><div class="">\@Thank you so much for reading my</div><div class="">\@ “contribution" &nbsp;Please tell me&nbsp;</div><div class="">\@what you think, I \\\\\\\\\\\\\value//////////// your opinion!</div><div class="">\@“””””””””””””””””””””” kind Regards! “”””””””””””””””"</div><div class="">\@ Ted.&nbsp;</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">(the previous text following \@ data lines are accepted as-is, including&nbsp;</div><div class="">the source-file’s linefeeds or crlf and the double quotes)&nbsp;</div><div class=""><br class=""></div><div class="">Of course, other tokens are possible as well.&nbsp;</div><div class=""><br class=""></div><div class="">Can’t be any simpler than this, I guess.</div><div class=""><br class=""></div><div class="">TedvG</div><div class=""><br class=""></div><div class="">===================As Previously Written:=================</div><div class=""><br class=""></div><div class=""><div class="">This could be a simple solution:&nbsp;</div><div class=""><br class=""></div><div class="">Starting each line with a special token.</div><div class=""><br class=""></div><div class="">In the example here it is the \\ &nbsp;double-backslash . &nbsp;</div><div class="">when the \\ appears in the first two columns of a source line,&nbsp;</div><div class="">this tells the compiler that it is a data line and that more might follow.</div><div class="">the last line starting with \\ completes the data entry.</div><div class=""><br class=""></div><div class="">Here is an example of a string declaration with some XML</div><div class="">(no escape sequences needed for “)&nbsp;</div><div class="">Of course it could be anything other kind of textual data as well.</div><div class=""><br class=""></div><div class="">let &nbsp;str = &nbsp;<div class=""><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\&lt;!DOCTYPE html&gt;</font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\&lt;html&gt;</font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\&lt;body&gt;</font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\</font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\&lt;h1&gt;W3Schools Internal Note&lt;/h1&gt;\n</font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\&lt;div&gt;</font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\&lt;b&gt;To:&lt;/b&gt; &lt;span id="to"&gt;&lt;/span&gt;&lt;br&gt;\n</font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\&lt;b&gt;From:&lt;/b&gt; &lt;span id="from"&gt;&lt;/span&gt;&lt;br&gt;\n</font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\&lt;b&gt;Message:&lt;/b&gt; &lt;span id="message"&gt;&lt;/span&gt;</font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\&lt;/div&gt;</font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\\n</font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\&lt;script&gt;</font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class=""><a href="smb://var" class="">\\var</a>&nbsp;txt, parser, xmlDoc;</font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class=""><a href="smb://txt" class="">\\txt</a>&nbsp;= "&lt;note&gt;" +</font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\"&lt;to&gt;Tove&lt;/to&gt;" +</font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class=""><a href="smb://etc" class="">\\etc</a>. this is the last data line.</font></div></div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Conditions:&nbsp;</div><div class=""><br class=""></div><div class="">- Every line starting with \\ in first and second column of the line&nbsp;</div><div class="">&nbsp; is &nbsp;treated as a data line.</div><div class="">- All characters behind the \\ are regarded as data, thus note that:</div><div class="">&nbsp; &nbsp; &nbsp;- the “ is not regarded as a string delimiter</div><div class="">&nbsp; &nbsp; &nbsp;- the // chars and whatever follows it are interpreted as data on such a line, not as comment.</div><div class="">&nbsp; &nbsp; &nbsp;- &nbsp;\\ &nbsp;within the data itself are treated as data e.g. this line is valid:</div><div class=""><a href="smb://There" class="">\\There</a>&nbsp;\\ are three backslashes (as data) in this line \\\\ today.</div><div class="">\\</div><div class="">the above data line is empty but is allowed.&nbsp;</div><div class=""><div class="">for \\</div><div class="">- Leading and embedded spaces are respected.</div><div class="">- Tabs, Linefeeds etc. can be inserted the usual way using \t \n etc.&nbsp;</div></div><div class=""><div class="">- trailing spaces and line terminators cr lf are ignored, filtered out.</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">============================================================</div><br class=""><br class=""></div><div class=""><span style="font-size: 13.800000190734863px;" class=""><br class=""></span></div><span style="font-size: 13.800000190734863px;" class="">&nbsp;</span><span style="font-size: 13.800000190734863px;" class="">Wed, 27 Apr 2016 16:08:13 +0300</span><span style="font-size: 13.800000190734863px;" class="">"Vladimir.S" &lt;</span><a href="mailto:svabox@gmail.com" style="font-size: 13.800000190734863px;" class="">svabox@gmail.com</a><span style="font-size: 13.800000190734863px;" class="">&gt; wrote:</span><br class=""><blockquote type="cite" class=""><span style="font-size: 13.800000190734863px;" class="">On 27.04.2016 11:52, Brent Royal-Gordon via swift-evolution wrote:</span><br style="font-size: 13.800000190734863px;" class=""><blockquote type="cite" style="font-size: 13.800000190734863px;" class=""><blockquote type="cite" class="">If you agree that these are all orthogonal pieces, then treat them as<br class="">such: I’d suggest that you provide a proposal that just tackles the<br class="">continuation string literals. &nbsp;This seems simple, and possible to get in<br class="">for Swift 3.<br class=""></blockquote><br class="">I've gone ahead and drafted this proposal, with some small extensions and<br class="">adjustments. See the "Draft Notes" section for details of what I've changed<br class="">and what concerns I have.<br class=""></blockquote><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">I don't feel like this proposal(draft) solves the issue we want(?) to solve&nbsp;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">with multi-line feature.</span><br style="font-size: 13.800000190734863px;" class=""><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">I expect to be able to have multiline text exactly *"as-is"* in my source&nbsp;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">file. No escaping, no interpolation, etc. I believe this should be a target&nbsp;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">of the proposal.</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">Otherwise, I reject to see any reason to introduce anything new at this&nbsp;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">area - we already can concatenate strings and place them on next line and&nbsp;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">escape special characters.</span><br style="font-size: 13.800000190734863px;" class=""><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">In your proposal, you have to escape characters in your text, you need to&nbsp;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">carefully modify the copy-pasted text to be allowed as correct multi-line&nbsp;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">string. Also, what if I need to have spaces *at the end of string* ? Editor&nbsp;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">can just trimmed them, and we can't clearly see them.</span><br style="font-size: 13.800000190734863px;" class=""><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">Personally I need to be able to have this(in some way) in my code:</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">(note this "\tuttorial" and "\(edition" - this is just text, I want to have&nbsp;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">inside my xml)</span><br style="font-size: 13.800000190734863px;" class=""><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">let xml = ... // some marker to start the multi-line str</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">&lt;?xml version="1.0"?&gt;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">&lt;catalog&gt;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">&nbsp;&nbsp;&nbsp;&nbsp;&lt;book id="myid" empty=""&gt;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;author&gt;myAuthor&lt;/author&gt;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;title&gt;myTitle \tutorial 1\(edition 2)&lt;/title&gt;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">&nbsp;&nbsp;&nbsp;&nbsp;&lt;/book&gt;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">&lt;/catalog&gt;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">... // some marker here to stop multi-line str</span><br style="font-size: 13.800000190734863px;" class=""><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">It seems like we need some markers for end-of-the-line to be able to keep&nbsp;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">spaces/tabs in the end of line.</span><br style="font-size: 13.800000190734863px;" class=""><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">What about something like this. Two suported variants : first when we need&nbsp;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">to keep spaces in the end of line, and second when we don't need&nbsp;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">spaced(will be trimmed by parser)</span><br style="font-size: 13.800000190734863px;" class=""><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">#1 (parser should just take the text between first and last quote *as-is*)</span><br style="font-size: 13.800000190734863px;" class=""><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">let xml = "\</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">"&lt;?xml version="1.0"?&gt; &nbsp;&nbsp;&nbsp;&nbsp;" // yes, *I need* these spaces at the end</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">"&lt;catalog&gt;"</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">" &nbsp;&nbsp;&nbsp;&lt;book id="myid" empty=""&gt;"</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">" &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;author&gt;myAuthor&lt;/author&gt;"</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">" &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;title&gt;myTitle \tutorial 1\(edition 2)&lt;/title&gt;"</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">" &nbsp;&nbsp;&nbsp;&lt;/book&gt;"</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">"&lt;/catalog&gt;"</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">"</span><br style="font-size: 13.800000190734863px;" class=""><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">#2 in this case we don't need any spaces/tabs in the end of lines(don't care):</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">(parser takes all that is after | as-is but trims any trailing spaces/tabs&nbsp;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">in lines to be clear in behaviour)</span><br style="font-size: 13.800000190734863px;" class=""><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">let xml = "\</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">|&lt;?xml version="1.0"?&gt;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">|&lt;catalog&gt;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">| &nbsp;&nbsp;&nbsp;&lt;book id="myid" empty=""&gt;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;author&gt;myAuthor&lt;/author&gt;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;title&gt;myTitle \tutorial 1\(edition 2)&lt;/title&gt;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">| &nbsp;&nbsp;&nbsp;&lt;/book&gt;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">|&lt;/catalog&gt;</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">"</span><br style="font-size: 13.800000190734863px;" class=""><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">Or these two could be combined in one(as-is between |..|) but I'm not sure:</span><br style="font-size: 13.800000190734863px;" class=""><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">let xml = "\</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">|&lt;?xml version="1.0"?&gt; &nbsp;&nbsp;&nbsp;&nbsp;| // yes, I need these spaces</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">|&lt;catalog&gt;| // we have to have closing symbol in this case in other lines</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">| &nbsp;&nbsp;&nbsp;&lt;book id="myid" empty=""&gt;|</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;author&gt;myAuthor&lt;/author&gt;|</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;title&gt;myTitle \tutorial 1\(edition 2)&lt;/title&gt;|</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">| &nbsp;&nbsp;&nbsp;&lt;/book&gt;|</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">|&lt;/catalog&gt;|</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">"</span><br style="font-size: 13.800000190734863px;" class=""><br style="font-size: 13.800000190734863px;" class=""><br style="font-size: 13.800000190734863px;" class=""><blockquote type="cite" style="font-size: 13.800000190734863px;" class=""><br class="">Gist: &lt;<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f</a>&gt;<br class=""><br class=""><br class="">&nbsp;Multiline string literals<br class=""><br class="">&nbsp;* Proposal: SE-NNNN<br class="">&nbsp;&nbsp;&nbsp;&lt;<a href="https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md</a>&gt;<br class="">&nbsp;* Author(s): Brent Royal-Gordon &lt;<a href="https://github.com/brentdax" class="">https://github.com/brentdax</a>&gt;<br class="">&nbsp;* Status: First Draft<br class="">&nbsp;* Review manager: TBD<br class=""><br class=""><br class="">&nbsp;&nbsp;&nbsp;&lt;<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#introduction" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#introduction</a>&gt;Introduction<br class=""><br class="">In Swift 2.2, the only means to insert a newline into a string literal is<br class="">the |\n| escape. String literals specified in this way are generally ugly<br class="">and unreadable. We propose a multiline string feature inspired by English<br class="">punctuation which is a straightforward extension of our existing string<br class="">literals.<br class=""><br class="">Swift-evolution thread: multi-line string literals.<br class="">&lt;<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160418/015500.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160418/015500.html</a>&gt;<br class=""><br class=""><br class="">&nbsp;&nbsp;&nbsp;&lt;<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#draft-notes" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#draft-notes</a>&gt;Draft<br class="">&nbsp;&nbsp;&nbsp;Notes<br class=""><br class="">&nbsp;*<br class=""><br class="">&nbsp;&nbsp;&nbsp;This draft differs from the prototypes being thrown around on the list<br class="">&nbsp;&nbsp;&nbsp;in that it specifies that comments should be treated as whitespace, and<br class="">&nbsp;&nbsp;&nbsp;that whitespace-only lines in the middle of a multiline string should<br class="">&nbsp;&nbsp;&nbsp;be ignored. I'm not sure if this is feasible from a parsing standpoint,<br class="">&nbsp;&nbsp;&nbsp;and I'd like feedback from implementers on this point.<br class=""><br class="">&nbsp;*<br class=""><br class="">&nbsp;&nbsp;&nbsp;This draft also specifies diagnostics which should be included.<br class="">&nbsp;&nbsp;&nbsp;Feedback on whether these are good choices would be welcome.<br class=""><br class="">&nbsp;*<br class=""><br class="">&nbsp;&nbsp;&nbsp;I am considering allowing you to put a backslash before the newline to<br class="">&nbsp;&nbsp;&nbsp;indicate it should /not/ be included in the literal. In other words,<br class="">&nbsp;&nbsp;&nbsp;this code:<br class=""><br class="">&nbsp;&nbsp;&nbsp;print("foo\<br class="">&nbsp;&nbsp;&nbsp;"bar")<br class=""><br class="">&nbsp;&nbsp;&nbsp;Would print |"foobar"|. However, I think this should probably be<br class="">&nbsp;&nbsp;&nbsp;proposed separately, because there may be a better way to do it.<br class=""><br class="">&nbsp;*<br class=""><br class="">&nbsp;&nbsp;&nbsp;I've listed only myself as an author because I don't want to put anyone<br class="">&nbsp;&nbsp;&nbsp;else's name to a document they haven't seen, but there are others who<br class="">&nbsp;&nbsp;&nbsp;deserve to be listed (John Holdsworth at least). Let me know if you<br class="">&nbsp;&nbsp;&nbsp;think you should be included.<br class=""><br class=""><br class="">&nbsp;&nbsp;&nbsp;&lt;<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#motivation" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#motivation</a>&gt;Motivation<br class=""><br class="">As Swift begins to move into roles beyond app development, code which needs<br class="">to generate text becomes a more important use case. Consider, for instance,<br class="">generating even a small XML string:<br class=""><br class="">let xml = "&lt;?xml version=\"1.0\"?&gt;\n&lt;catalog&gt;\n\t&lt;book id=\"bk101\"<br class="">empty=\"\"&gt;\n\t\t&lt;author&gt;\(author)&lt;/author&gt;\n\t&lt;/book&gt;\n&lt;/catalog&gt;"<br class=""><br class="">The string is practically unreadable, its structure drowned in escapes and<br class="">run-together characters; it looks like little more than line noise. We can<br class="">improve its readability somewhat by concatenating separate strings for each<br class="">line and using real tabs instead of |\t| escapes:<br class=""><br class="">let xml = "&lt;?xml version=\"1.0\"?&gt;\n" +<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"&lt;catalog&gt;\n" +<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;" &lt;book id=\"bk101\" empty=\"\"&gt;\n" +<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;" &lt;author&gt;\(author)&lt;/author&gt;\n" +<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;" &lt;/book&gt;\n" +<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"&lt;/catalog&gt;"<br class=""><br class="">However, this creates a more complex expression for the type checker, and<br class="">there's still far more punctuation than ought to be necessary. If the most<br class="">important goal of Swift is making code readable, this kind of code falls<br class="">far short of that goal.<br class=""><br class=""><br class="">&nbsp;&nbsp;&nbsp;&lt;<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#proposed-solution" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#proposed-solution</a>&gt;Proposed<br class="">&nbsp;&nbsp;&nbsp;solution<br class=""><br class="">We propose that, when Swift is parsing a string literal, if it reaches the<br class="">end of the line without encountering an end quote, it should look at the<br class="">next line. If it sees a quote mark there (a "continuation quote"), the<br class="">string literal contains a newline and then continues on that line.<br class="">Otherwise, the string literal is unterminated and syntactically invalid.<br class=""><br class="">Our sample above could thus be written as:<br class=""><br class="">let xml = "&lt;?xml version=\"1.0\"?&gt;<br class="">"&lt;catalog&gt;<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;" &lt;book id=\"bk101\" empty=\"\"&gt;<br class="">" &nbsp;&nbsp;&nbsp;&nbsp;&lt;author&gt;\(author)&lt;/author&gt;<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;" &lt;/book&gt;<br class="">"&lt;/catalog&gt;"<br class=""><br class="">(Note that GitHub is applying incorrect syntax highlighting to this code<br class="">sample, because it's applying Swift 2 rules.)<br class=""><br class="">This format's unbalanced quotes might strike some programmers as strange,<br class="">but it attempts to mimic the way multiple lines are quoted in English<br class="">prose. As an English Stack Exchange answer illustrates<br class="">&lt;<a href="http://english.stackexchange.com/a/96613/64636" class="">http://english.stackexchange.com/a/96613/64636</a>&gt;:<br class=""><br class="">&nbsp;&nbsp;&nbsp;“That seems like an odd way to use punctuation,” Tom said. “What harm<br class="">&nbsp;&nbsp;&nbsp;would there be in using quotation marks at the end of every paragraph?”<br class=""><br class="">&nbsp;&nbsp;&nbsp;“Oh, that’s not all that complicated,” J.R. answered. “If you closed<br class="">&nbsp;&nbsp;&nbsp;quotes at the end of every paragraph, then you would need to reidentify<br class="">&nbsp;&nbsp;&nbsp;the speaker with every subsequent paragraph.<br class=""><br class="">&nbsp;&nbsp;&nbsp;“Say a narrative was describing two or three people engaged in a<br class="">&nbsp;&nbsp;&nbsp;lengthy conversation. If you closed the quotation marks in the previous<br class="">&nbsp;&nbsp;&nbsp;paragraph, then a reader wouldn’t be able to easily tell if the<br class="">&nbsp;&nbsp;&nbsp;previous speaker was extending his point, or if someone else in the<br class="">&nbsp;&nbsp;&nbsp;room had picked up the conversation. By leaving the previous<br class="">&nbsp;&nbsp;&nbsp;paragraph’s quote unclosed, the reader knows that the previous speaker<br class="">&nbsp;&nbsp;&nbsp;is still the one talking.”<br class=""><br class="">&nbsp;&nbsp;&nbsp;“Oh, that makes sense. Thanks!”<br class=""><br class="">Similarly, omitting the ending quotation mark tells the code's reader (and<br class="">compiler) that the literal continues on the next line, while including the<br class="">continuation quote reminds the reader (and compiler) that this line is part<br class="">of a string literal.<br class=""><br class=""><br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#benefits-of-continuation-quotes" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#benefits-of-continuation-quotes</a>&gt;Benefits<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of continuation quotes<br class=""><br class="">It would be simpler to not require continuation quotes, so why are they<br class="">required by this proposal? There are three reasons:<br class=""><br class="">1.<br class=""><br class="">&nbsp;&nbsp;&nbsp;*They help the compiler pinpoint errors in string literal<br class="">&nbsp;&nbsp;&nbsp;delimiting.* If continuation quotes were not required, then a missing<br class="">&nbsp;&nbsp;&nbsp;end quote would be interpreted as a multiline string literal. This<br class="">&nbsp;&nbsp;&nbsp;string literal would continue until the compiler encountered either<br class="">&nbsp;&nbsp;&nbsp;another quote mark—perhaps at the site of another string literal or in<br class="">&nbsp;&nbsp;&nbsp;a comment—or the end of the file. In either case, the compiler could at<br class="">&nbsp;&nbsp;&nbsp;best only indicate the start of the runaway string literal; in<br class="">&nbsp;&nbsp;&nbsp;pathological cases (for instance, if the next string literal<br class="">&nbsp;&nbsp;&nbsp;was |"+"|), it might not even be able to do that properly.<br class=""><br class="">&nbsp;&nbsp;&nbsp;With continuation quotes required, if you forget to include an end<br class="">&nbsp;&nbsp;&nbsp;quote, the compiler can tell that you did not intend to create a<br class="">&nbsp;&nbsp;&nbsp;multiline string and flag the line that actually has the problem. It<br class="">&nbsp;&nbsp;&nbsp;can also provide immediately actionable fix-it assistance. The fact<br class="">&nbsp;&nbsp;&nbsp;that there is a redundant indication on each line of the programmer's<br class="">&nbsp;&nbsp;&nbsp;intent to include that line in a multiline quote allows the compiler to<br class="">&nbsp;&nbsp;&nbsp;guess the meaning of the code.<br class=""><br class="">2.<br class=""><br class="">&nbsp;&nbsp;&nbsp;*They separate indentation from the string's contents.* Without<br class="">&nbsp;&nbsp;&nbsp;continuation quotes, there would be no obvious indication of whether<br class="">&nbsp;&nbsp;&nbsp;whitespace at the start of the line was intended to indent the string<br class="">&nbsp;&nbsp;&nbsp;literal so it matched the surrounding code, or whether that whitespace<br class="">&nbsp;&nbsp;&nbsp;was actually meant to be included in the resulting string. Multiline<br class="">&nbsp;&nbsp;&nbsp;string literals would either have to put subsequent lines against the<br class="">&nbsp;&nbsp;&nbsp;left margin, or apply error-prone heuristics to try to guess which<br class="">&nbsp;&nbsp;&nbsp;whitespace was indentation and which was string literal content.<br class=""><br class="">3.<br class=""><br class="">&nbsp;&nbsp;&nbsp;*They improve the ability to quickly recognize the literal.* The |"| on<br class="">&nbsp;&nbsp;&nbsp;each line serves as an immediately obvious indication that the line is<br class="">&nbsp;&nbsp;&nbsp;part of a string literal, not code, and the row of |"| characters in a<br class="">&nbsp;&nbsp;&nbsp;well-formatted file allows you to quickly scan up and down the file to<br class="">&nbsp;&nbsp;&nbsp;see the extent of the literal.<br class=""><br class=""><br class="">&nbsp;&nbsp;&nbsp;&lt;<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#detailed-design" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#detailed-design</a>&gt;Detailed<br class="">&nbsp;&nbsp;&nbsp;design<br class=""><br class="">When Swift is parsing a string literal and reaches the end of a line<br class="">without finding a closing quote, it examines the next line, applying the<br class="">following rules:<br class=""><br class="">1.<br class=""><br class="">&nbsp;&nbsp;&nbsp;If the next line is all whitespace, it is ignored; Swift moves on to<br class="">&nbsp;&nbsp;&nbsp;the line afterward, applying these rules again.<br class=""><br class="">2.<br class=""><br class="">&nbsp;&nbsp;&nbsp;If the next line begins with whitespace followed by a continuation<br class="">&nbsp;&nbsp;&nbsp;quote, then the string literal contains a newline followed by the<br class="">&nbsp;&nbsp;&nbsp;contents of the string literal starting on that line. (This line may<br class="">&nbsp;&nbsp;&nbsp;itself have no closing quote, in which case the same rules apply to the<br class="">&nbsp;&nbsp;&nbsp;line which follows.)<br class=""><br class="">3.<br class=""><br class="">&nbsp;&nbsp;&nbsp;If the next line contains anything else, Swift raises a syntax error<br class="">&nbsp;&nbsp;&nbsp;for an unterminated string literal. This syntax error should offer two<br class="">&nbsp;&nbsp;&nbsp;fix-its: one to close the string literal at the end of the current<br class="">&nbsp;&nbsp;&nbsp;line, and one to include the next line in the string literal by<br class="">&nbsp;&nbsp;&nbsp;inserting a continuation quote.<br class=""><br class="">Rules 1 and 2 should treat comments as though they are whitespace; this<br class="">allows you to comment out individual lines in a multiline string literal.<br class="">(However, commenting out the last line of the string literal will still<br class="">make it unterminated, so you don't have a completely free hand in commenting.)<br class=""><br class=""><br class="">&nbsp;&nbsp;&nbsp;&lt;<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#impact-on-existing-code" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#impact-on-existing-code</a>&gt;Impact<br class="">&nbsp;&nbsp;&nbsp;on existing code<br class=""><br class="">Failing to close a string literal before the end of the line is currently a<br class="">syntax error, so no valid Swift code should be affected by this change.<br class=""><br class=""><br class="">&nbsp;&nbsp;&nbsp;&lt;<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#alternatives-considered" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#alternatives-considered</a>&gt;Alternatives<br class="">&nbsp;&nbsp;&nbsp;considered<br class=""><br class=""><br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#requiring-no-continuation-character" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#requiring-no-continuation-character</a>&gt;Requiring<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;no continuation character<br class=""><br class="">The main alternative is to not require a continuation quote, and simply<br class="">extend the string literal from the starting quote to the ending quote,<br class="">including all newlines between them. For example:<br class=""><br class="">let xml = "&lt;?xml version=\"1.0\"?&gt;<br class="">&lt;catalog&gt;<br class="">&lt;book id=\"bk101\" empty=\"\"&gt;<br class="">&lt;author&gt;\(author)&lt;/author&gt;<br class="">&lt;/book&gt;<br class="">&lt;/catalog&gt;"<br class=""><br class="">This has several advantages:<br class=""><br class="">1.<br class=""><br class="">&nbsp;&nbsp;&nbsp;It is simpler.<br class=""><br class="">2.<br class=""><br class="">&nbsp;&nbsp;&nbsp;It is less offensive to programmers' sensibilities (since there are no<br class="">&nbsp;&nbsp;&nbsp;unmatched |"| characters).<br class=""><br class="">3.<br class=""><br class="">&nbsp;&nbsp;&nbsp;It does not require that you edit the string literal to insert a<br class="">&nbsp;&nbsp;&nbsp;continuation quote in each line.<br class=""><br class="">Balanced against the advantages, however, is the loss of the improved<br class="">diagnostics, code formatting, and visual affordances mentioned in the<br class="">"Benefits of continuation quotes" section above.<br class=""><br class="">In practice, we believe that editor support (such as "Paste as String<br class="">Literal" or "Convert to String Literal" commands) can make adding<br class="">continuation quotes less burdensome, while also providing other<br class="">conveniences like automatic escaping. We believe the other two factors are<br class="">outweighed by the benefits of continuation quotes.<br class=""><br class=""><br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#use-a-different-delimiter-for-multiline-strings" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#use-a-different-delimiter-for-multiline-strings</a>&gt;Use<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a different delimiter for multiline strings<br class=""><br class="">The initial suggestion was that multiline strings should use a different<br class="">delimiter, |"""|, at the beginning and end of the string, with no<br class="">continuation characters between. This solution was rejected because it has<br class="">the same issues as the "no continuation character" solution, and because it<br class="">was mixing two orthogonal issues (multiline strings and alternate delimiters).<br class=""><br class="">Another suggestion was to support a heredoc syntax, which would allow you<br class="">to specify a placeholder string literal on one line whose content begins on<br class="">the next line, running until some arbitrary delimiter. For instance, if<br class="">Swift adopted Perl 5's syntax, it might support code like:<br class=""><br class="">connection.sendString(&lt;&lt;"END")<br class="">&lt;?xml version="1.0"?&gt;<br class="">&lt;catalog&gt;<br class="">&nbsp;&nbsp;&nbsp;&lt;book id="bk101" empty=""&gt;<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;author&gt;\(author)&lt;/author&gt;<br class="">&nbsp;&nbsp;&nbsp;&lt;/book&gt;<br class="">&lt;/catalog&gt;<br class="">END<br class=""><br class="">In addition to the issues with the |"""| syntax, heredocs are complicated<br class="">both to explain and to parse, and are not a natural extension of Swift's<br class="">current string syntax.<br class=""><br class="">Both of these suggestions address interesting issues with string literals,<br class="">solving compelling use cases. They're just not that good at fixing the<br class="">specific issue at hand. We might consider them in the future to address<br class="">those problems to which they are better suited.<br class=""><br class=""><br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#fixing-other-string-literal-readability-issues" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#fixing-other-string-literal-readability-issues</a>&gt;Fixing<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;other string literal readability issues<br class=""><br class="">This proposal is narrowly aimed at multiline strings. It intentionally<br class="">doesn't tackle several other problems with string literals:<br class=""><br class="">&nbsp;*<br class=""><br class="">&nbsp;&nbsp;&nbsp;Reducing the amount of double-backslashing needed when working with<br class="">&nbsp;&nbsp;&nbsp;regular expression libraries, Windows paths, source code generation,<br class="">&nbsp;&nbsp;&nbsp;and other tasks where backslashes are part of the data.<br class=""><br class="">&nbsp;*<br class=""><br class="">&nbsp;&nbsp;&nbsp;Alternate delimiters or other strategies for writing strings<br class="">&nbsp;&nbsp;&nbsp;with |"| characters in them.<br class=""><br class="">&nbsp;*<br class=""><br class="">&nbsp;&nbsp;&nbsp;String literals consisting of very long pieces of text which are best<br class="">&nbsp;&nbsp;&nbsp;represented completely verbatim.<br class=""><br class="">These are likely to be subjects of future proposals, though not necessarily<br class="">during Swift 3.<br class=""><br class="">This proposal also does not attempt to address regular expression literals.<br class="">The members of the core team who are interested in regular expression<br class="">support have ambitions for that feature which put it out of scope for Swift 3.<br class=""><br class="">--<br class="">Brent Royal-Gordon<br class="">Architechies<br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""><br class=""></blockquote></blockquote></body></html>