<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=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>let xml = _"<?xml version="1.0"?><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span> "<catalog><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span> " <book id="bk101" empty=""><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span> " <author>\(author)</author><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span> " </book><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span> "</catalog>”_<br class=""></blockquote></blockquote><br class=""><div class="">If I am reading and understanding this correctly:</div><div class="">This solution is still delimiter-sensitive and</div><div class="">breaks if “_ delimiter is found somewhere within the data,</div><div class="">because it is interpreted as end-of-string.</div><div class=""><br class=""></div><div class="">I wrote already about my solution </div><div class="">which solves the above deficiency, </div><div class="">because it does not use delimiters at all.</div><div class=""><br class=""></div><div class="">I have thought it all over and cleaned it up. Here it is again,</div><div class="">hopefully this description is more clear and readable.</div><div class=""><br class=""></div><div class="">Data Line Operators. </div><div class=""><br class=""></div><div class=""><div class="">For convenience, I call these \\ and \@ : “data-line-operators” .</div><div class="">(of course, they are pseudo operators) </div><div class="">Other two? character combinations for these operators are also possible. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="">The \@ data-line-operator: </div><div class=""> - takes character data "as-is” without any conversion.</div><div class=""> - respects (includes) source-file line terminators.</div></div><div class=""> - all spaces in-between and up to the source line's end are included.</div><div class=""> - comments // are not seen as comments but read as data. </div><div class=""> - the \@ on its own (without anything else to the right) is implicitly an empty line. </div><div class=""> </div><div class=""><br class=""></div><div class=""><div class="">The \\ data-line-operator: </div><div class=""> - converts escaped chars like \t \n and \(var) substitution, as with “normal" string literals.</div><div class=""> - ignores trailing spaces and source-file line terminators.</div></div><div class=""> - respects // comments on the same line and will not include these as data. </div><div class=""> - the \\ on its own is interpreted as \n (line feed) thus (optionally) eliminating the </div><div class=""> need for \n usage. </div></div><div class=""><br class=""></div><div class="">Both operators allow 0…n spaces/tabs on its left side, </div><div class="">thus indentation is supported.</div><div class=""><br class=""></div><div class="">Example 1. The \@ operator: </div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span> // 1. multi-line string literal with data lines as is. </div><div class=""> // It loads each line (part) up to and including the source-file-line- end:</div><div class=""><div class=""> // you can use all available characters without problems, </div><div class=""> // even \\ and \@ thus allowing you to nest e.g. Swift statements... </div><div class=""> </div><div class=""> let xml = </div><div class=""> \@<?xml version="1.0"?><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span> \@ <catalog><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span> \@ <book id="bk101" empty=“”> // this is not regarded as a comment.<br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span> \@ <author>//<span style="background-color: rgb(255, 255, 255);" class=""><font color="#2c353c" face="Source Sans Pro, Helvetica Neue, Helvetica, Roboto, Arial, sans-serif" size="3" class=""><i class="">¯\"_(ツ)_//</i></font></span></author></div><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span> \@ </book></div><div class=""> \@ </catalog> </div><div class=""> </div></div><div class=""><br class=""></div><div class=""> Example 2, The \\ operator: </div><div class=""> // Multi-line string literal with data lines with \n \t etc. respected: </div><div class=""><br class=""></div><div class=""> var str =</div><div class=""> <a href="smb://This" class="">\\This</a> is line one.\nThis is line two, with a few \t\t\t tabs in it...</div><div class=""> \\ </div><div class=""> <a href="smb://This" class="">\\This</a> is line three: there are \(cars) // this is a comment.</div><div class=""> \\ waiting in the garage. This is still line three</div><div class=""><br class=""></div><div class=""> The first \@ or \\ must be on a new line, this is an error:</div><div class=""><br class=""></div><div class=""> let str = /@data data data data…...</div><div class=""> /@data………….</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="">A block of \@ or \\ lines must be contiguous: with no other lines in-between.</div><div class="">An empty line or other source line implicitly ends the </div><div class="">\\ or \@ block of lines. There is no terminator. </div><div class=""><br class=""></div></div><div class=""> \@ and \\ lines can be mixed together in the same block.</div><div class=""> Should this be allowed? </div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Imho even easier to understand and simple.</div><div class=""><br class=""></div><div class=""><div class="">I could make a proposal for this later in May.</div></div><div class=""><br class=""></div><div class="">@Vladimir: sorry I didn’t respond directly on your email</div><div class="">You’re right. Our ideas about this have some similarity? </div><div class="">Your point: </div><div class=""> "and I believe I can prove we need some start-of-line marker)” :</div><div class=""> I think so too, that’s why I suggest the \\ and \@ data-line-operators. </div><div class="">as described here. </div><div class=""><br class=""></div><div class="">Too busy, packing things to move to <a href="http://www.speyer.de" class="">www.speyer.de</a></div><div class="">I will read swift-evolution, but will probably not</div><div class="">respond until after the 12th of May or so.</div><div class=""><br class=""></div><div class="">Although away, some feedback would be nice, thank you.</div><div class=""><br class=""></div><div class="">Kind Regards</div><div class="">TedvG</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Fri, 29 Apr 2016 08:20:34 -0600 Erica Sadun wrote: <br class=""><br class=""><blockquote type="cite" class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" class="">On Apr 28, 2016, at 4:52 PM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Did you ever really use multiline string literals before?<br class=""></blockquote><br class="">Yes. I used Perl in the CGI script era. Believe me, I have used every quoting syntax it supports extensively, including `'` strings, `"` strings, `q` strings, `qq` strings, and heredocs. This proposal is educated by knowledge of their foibles.<br class=""><br class="">As outlined in the "Future directions for string literals in general" section, I believe alternate delimiters (so you can embed quotes) are a separate feature and should be handled in a separate proposal. Once both features are available, they can be combined. For instance, using the `_"foo"_` syntax I sketch there for alternate delimiters, you could say:<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>let xml = _"<?xml version="1.0"?><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span> "<catalog><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span> " <book id="bk101" empty=""><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span> " <author>\(author)</author><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span> " </book><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span> "</catalog>"_<br class=""></blockquote><br class="">Other than the underscores (I'm not sold on them but I could live with them), this is my favorite approach:<br class=""><br class="">* It supports indented left-hand alignment, which is an important to me for readability</blockquote><blockquote type="cite" class="">* It avoids painful `\n"+` RHS constructions<br class=""></blockquote> ^ what are RHS constructions ? <br class=""><blockquote type="cite" class="">* It's easy to scan and understand<br class="">* It's simple and harmonious<br class=""></blockquote> <blockquote type="cite" class="">— E<br class=""></blockquote></div><div class=""><br class=""></div></body></html>