<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=""> - They need a specific delimiter token, which cannot be used in the text itself.</div><div class=""> - The data cannot be used as-is, escape \ characters are needed.</div><div class=""> - Imho, they are somewhat complicated. </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? </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: </div></div><div class=""><br class=""></div><div class="">In the mean time I consider using two tokens \\ and \@: </div><div class=""> <a href="smb://…data…data…data…data" class="">\\…data…data…data…data</a>………….. accepts data and converts \n \t etc.</div><div class="">or data lines starting with: </div><div class=""> \@…data…data…data…data… .……. accepts data as-is, without conversion and </div><div class=""> 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, </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="">\\ can be\t\t\t\tIt is \”Magic\” really.</div><div class=""> </div><div class="">If you do or don’t like this solution </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" Please tell me </div><div class="">\@what you think, I \\\\\\\\\\\\\value//////////// your opinion!</div><div class="">\@“””””””””””””””””””””” kind Regards! “”””””””””””””””"</div><div class="">\@ Ted. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">(the previous text following \@ data lines are accepted as-is, including </div><div class="">the source-file’s linefeeds or crlf and the double quotes) </div><div class=""><br class=""></div><div class="">Of course, other tokens are possible as well. </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: </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 \\ double-backslash . </div><div class="">when the \\ appears in the first two columns of a source line, </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 “) </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 str = <div class=""><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\<!DOCTYPE html></font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\<html></font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\<body></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="">\\<h1>W3Schools Internal Note</h1>\n</font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\<div></font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\<b>To:</b> <span id="to"></span><br>\n</font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\<b>From:</b> <span id="from"></span><br>\n</font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\<b>Message:</b> <span id="message"></span></font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\</div></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="">\\<script></font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class=""><a href="smb://var" class="">\\var</a> 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> = "<note>" +</font></div><div class="" style="text-align: justify;"><font face="Open Sans, Arial, sans-serif" class="">\\"<to>Tove</to>" +</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: </div><div class=""><br class=""></div><div class="">- Every line starting with \\ in first and second column of the line </div><div class=""> is treated as a data line.</div><div class="">- All characters behind the \\ are regarded as data, thus note that:</div><div class=""> - the “ is not regarded as a string delimiter</div><div class=""> - the // chars and whatever follows it are interpreted as data on such a line, not as comment.</div><div class=""> - \\ within the data itself are treated as data e.g. this line is valid:</div><div class=""><a href="smb://There" class="">\\There</a> \\ are three backslashes (as data) in this line \\\\ today.</div><div class="">\\</div><div class="">the above data line is empty but is allowed. </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. </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=""> </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" <</span><a href="mailto:svabox@gmail.com" style="font-size: 13.800000190734863px;" class="">svabox@gmail.com</a><span style="font-size: 13.800000190734863px;" class="">> 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. 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 </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 </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 </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 </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 </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 </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 </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 </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 </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=""><?xml version="1.0"?></span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class=""><catalog></span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class=""> <book id="myid" empty=""></span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class=""> <author>myAuthor</author></span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class=""> <title>myTitle \tutorial 1\(edition 2)</title></span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class=""> </book></span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class=""></catalog></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 </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 </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 </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="">"<?xml version="1.0"?> " // yes, *I need* these spaces at the end</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">"<catalog>"</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">" <book id="myid" empty="">"</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">" <author>myAuthor</author>"</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">" <title>myTitle \tutorial 1\(edition 2)</title>"</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">" </book>"</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">"</catalog>"</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 </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="">|<?xml version="1.0"?></span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">|<catalog></span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">| <book id="myid" empty=""></span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">| <author>myAuthor</author></span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">| <title>myTitle \tutorial 1\(edition 2)</title></span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">| </book></span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">|</catalog></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="">|<?xml version="1.0"?> | // yes, I need these spaces</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">|<catalog>| // 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="">| <book id="myid" empty="">|</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">| <author>myAuthor</author>|</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">| <title>myTitle \tutorial 1\(edition 2)</title>|</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">| </book>|</span><br style="font-size: 13.800000190734863px;" class=""><span style="font-size: 13.800000190734863px;" class="">|</catalog>|</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: <<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f</a>><br class=""><br class=""><br class=""> Multiline string literals<br class=""><br class=""> * Proposal: SE-NNNN<br class=""> <<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>><br class=""> * Author(s): Brent Royal-Gordon <<a href="https://github.com/brentdax" class="">https://github.com/brentdax</a>><br class=""> * Status: First Draft<br class=""> * Review manager: TBD<br class=""><br class=""><br class=""> <<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#introduction" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#introduction</a>>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=""><<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>><br class=""><br class=""><br class=""> <<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#draft-notes" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#draft-notes</a>>Draft<br class=""> Notes<br class=""><br class=""> *<br class=""><br class=""> This draft differs from the prototypes being thrown around on the list<br class=""> in that it specifies that comments should be treated as whitespace, and<br class=""> that whitespace-only lines in the middle of a multiline string should<br class=""> be ignored. I'm not sure if this is feasible from a parsing standpoint,<br class=""> and I'd like feedback from implementers on this point.<br class=""><br class=""> *<br class=""><br class=""> This draft also specifies diagnostics which should be included.<br class=""> Feedback on whether these are good choices would be welcome.<br class=""><br class=""> *<br class=""><br class=""> I am considering allowing you to put a backslash before the newline to<br class=""> indicate it should /not/ be included in the literal. In other words,<br class=""> this code:<br class=""><br class=""> print("foo\<br class=""> "bar")<br class=""><br class=""> Would print |"foobar"|. However, I think this should probably be<br class=""> proposed separately, because there may be a better way to do it.<br class=""><br class=""> *<br class=""><br class=""> I've listed only myself as an author because I don't want to put anyone<br class=""> else's name to a document they haven't seen, but there are others who<br class=""> deserve to be listed (John Holdsworth at least). Let me know if you<br class=""> think you should be included.<br class=""><br class=""><br class=""> <<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#motivation" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#motivation</a>>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 = "<?xml version=\"1.0\"?>\n<catalog>\n\t<book id=\"bk101\"<br class="">empty=\"\">\n\t\t<author>\(author)</author>\n\t</book>\n</catalog>"<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 = "<?xml version=\"1.0\"?>\n" +<br class=""> "<catalog>\n" +<br class=""> " <book id=\"bk101\" empty=\"\">\n" +<br class=""> " <author>\(author)</author>\n" +<br class=""> " </book>\n" +<br class=""> "</catalog>"<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=""> <<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#proposed-solution" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#proposed-solution</a>>Proposed<br class=""> 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 = "<?xml version=\"1.0\"?><br class="">"<catalog><br class=""> " <book id=\"bk101\" empty=\"\"><br class="">" <author>\(author)</author><br class=""> " </book><br class="">"</catalog>"<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=""><<a href="http://english.stackexchange.com/a/96613/64636" class="">http://english.stackexchange.com/a/96613/64636</a>>:<br class=""><br class=""> “That seems like an odd way to use punctuation,” Tom said. “What harm<br class=""> would there be in using quotation marks at the end of every paragraph?”<br class=""><br class=""> “Oh, that’s not all that complicated,” J.R. answered. “If you closed<br class=""> quotes at the end of every paragraph, then you would need to reidentify<br class=""> the speaker with every subsequent paragraph.<br class=""><br class=""> “Say a narrative was describing two or three people engaged in a<br class=""> lengthy conversation. If you closed the quotation marks in the previous<br class=""> paragraph, then a reader wouldn’t be able to easily tell if the<br class=""> previous speaker was extending his point, or if someone else in the<br class=""> room had picked up the conversation. By leaving the previous<br class=""> paragraph’s quote unclosed, the reader knows that the previous speaker<br class=""> is still the one talking.”<br class=""><br class=""> “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=""> <<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#benefits-of-continuation-quotes" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#benefits-of-continuation-quotes</a>>Benefits<br class=""> 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=""> *They help the compiler pinpoint errors in string literal<br class=""> delimiting.* If continuation quotes were not required, then a missing<br class=""> end quote would be interpreted as a multiline string literal. This<br class=""> string literal would continue until the compiler encountered either<br class=""> another quote mark—perhaps at the site of another string literal or in<br class=""> a comment—or the end of the file. In either case, the compiler could at<br class=""> best only indicate the start of the runaway string literal; in<br class=""> pathological cases (for instance, if the next string literal<br class=""> was |"+"|), it might not even be able to do that properly.<br class=""><br class=""> With continuation quotes required, if you forget to include an end<br class=""> quote, the compiler can tell that you did not intend to create a<br class=""> multiline string and flag the line that actually has the problem. It<br class=""> can also provide immediately actionable fix-it assistance. The fact<br class=""> that there is a redundant indication on each line of the programmer's<br class=""> intent to include that line in a multiline quote allows the compiler to<br class=""> guess the meaning of the code.<br class=""><br class="">2.<br class=""><br class=""> *They separate indentation from the string's contents.* Without<br class=""> continuation quotes, there would be no obvious indication of whether<br class=""> whitespace at the start of the line was intended to indent the string<br class=""> literal so it matched the surrounding code, or whether that whitespace<br class=""> was actually meant to be included in the resulting string. Multiline<br class=""> string literals would either have to put subsequent lines against the<br class=""> left margin, or apply error-prone heuristics to try to guess which<br class=""> whitespace was indentation and which was string literal content.<br class=""><br class="">3.<br class=""><br class=""> *They improve the ability to quickly recognize the literal.* The |"| on<br class=""> each line serves as an immediately obvious indication that the line is<br class=""> part of a string literal, not code, and the row of |"| characters in a<br class=""> well-formatted file allows you to quickly scan up and down the file to<br class=""> see the extent of the literal.<br class=""><br class=""><br class=""> <<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#detailed-design" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#detailed-design</a>>Detailed<br class=""> 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=""> If the next line is all whitespace, it is ignored; Swift moves on to<br class=""> the line afterward, applying these rules again.<br class=""><br class="">2.<br class=""><br class=""> If the next line begins with whitespace followed by a continuation<br class=""> quote, then the string literal contains a newline followed by the<br class=""> contents of the string literal starting on that line. (This line may<br class=""> itself have no closing quote, in which case the same rules apply to the<br class=""> line which follows.)<br class=""><br class="">3.<br class=""><br class=""> If the next line contains anything else, Swift raises a syntax error<br class=""> for an unterminated string literal. This syntax error should offer two<br class=""> fix-its: one to close the string literal at the end of the current<br class=""> line, and one to include the next line in the string literal by<br class=""> 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=""> <<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#impact-on-existing-code" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#impact-on-existing-code</a>>Impact<br class=""> 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=""> <<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#alternatives-considered" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#alternatives-considered</a>>Alternatives<br class=""> considered<br class=""><br class=""><br class=""> <<a href="https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#requiring-no-continuation-character" class="">https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#requiring-no-continuation-character</a>>Requiring<br class=""> 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 = "<?xml version=\"1.0\"?><br class=""><catalog><br class=""><book id=\"bk101\" empty=\"\"><br class=""><author>\(author)</author><br class=""></book><br class=""></catalog>"<br class=""><br class="">This has several advantages:<br class=""><br class="">1.<br class=""><br class=""> It is simpler.<br class=""><br class="">2.<br class=""><br class=""> It is less offensive to programmers' sensibilities (since there are no<br class=""> unmatched |"| characters).<br class=""><br class="">3.<br class=""><br class=""> It does not require that you edit the string literal to insert a<br class=""> 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=""> <<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>>Use<br class=""> 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(<<"END")<br class=""><?xml version="1.0"?><br class=""><catalog><br class=""> <book id="bk101" empty=""><br class=""> <author>\(author)</author><br class=""> </book><br class=""></catalog><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=""> <<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>>Fixing<br class=""> 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=""> *<br class=""><br class=""> Reducing the amount of double-backslashing needed when working with<br class=""> regular expression libraries, Windows paths, source code generation,<br class=""> and other tasks where backslashes are part of the data.<br class=""><br class=""> *<br class=""><br class=""> Alternate delimiters or other strategies for writing strings<br class=""> with |"| characters in them.<br class=""><br class=""> *<br class=""><br class=""> String literals consisting of very long pieces of text which are best<br class=""> 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>