<html><head></head><body class="ApplePlainTextBody" dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><blockquote type="cite">Would you all be so kind to take a look at what I suggested<br>and wrote appr. a week ago? (data lines) <br>This is with using:<br> \@ for verbatim as-is character data <br>and<br> \\ for character data with processing of \ escaped chars and \(var)<br><br>The advantage of what I describe is that apart from that a data line starts with<br> \@ or \\<br>No delimiters involved at the start and end of a pack of data lines,<br>which, if I have seen this correctly, is nowhere the case with the other suggestions<br>here.<br></blockquote><br>I addressed suggestions of that type in the third draft of the proposal (although the precise example I used was using `"` as the data line marker):<br><br>### Don't require the end quote<br><br>Since each line is marked with a continuation quote, in theory, the end <br>quote is redundant; the string could simply end after the last line <br>with a continuation quote.<br><br>```<br>// Something like:<br>let xml = M"<?xml version="1.0"?><br> "<catalog><br> "<span class="Apple-tab-span" style="white-space:pre"> </span><book id="bk101" empty=""><br> "<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><author>\(author)</author><br> "<span class="Apple-tab-span" style="white-space:pre"> </span></book><br> "</catalog><br>```<br><br>Alternatively, the `M` modifier could be left out (which would require <br>quotes on that line to be escaped), or a different <br>character or character sequence could be used. There was a fair bit of <br>bikeshedding on this; in some cases, a single post suggested several <br>syntaxes with slightly different semantics (such as different escaping <br>rules). Some marked the first and/or last line differently from the <br>other lines. What they all have in common is that the beginning of each <br>line is marked in some way, but the end is not, even at the end of the <br>literal.<br><br>Because there is no end delimiter—only a start-of-line marker—these <br>designs may not require you to escape quotes; thus, they could <br>potentially obviate the need for an alternate delimiter feature as <br>well. Depending on the design, however, many of them have issues:<br><br>* In most designs, it is possible to create a single-line string with <br> the feature, but the resulting code tends to be ugly and awkward.<br><br>* If the last line is marked the same as the others and the user forgets <br> the marker on a line, the compiler has no way to notice, except by <br> diagnosing errors caused by treating a line of a string literal as <br> code. Since some lines of string content will be valid code (such as <br> blank lines or C-style comments), these mistakes may pass unnoticed.<br><br>* If the last line is marked the same as the others, then commenting <br> out a line of a string literal, inserting a blank line in the middle <br> of a string literal, or just in general inserting some sort of valid <br> Swift code in the middle of a string literal would break the literal <br> in half, once again potentially forming syntactically valid but <br> incorrect Swift code.<br><br>* Generally, the more these constructs work to avoid the above <br> problems, the uglier and less quote-like they end up looking, and <br> the more complex they will be for the parser.<br><br>Finally, all approaches share one fundamental issue.<br><br>String literals are expressions, and so they ought to have a syntax <br>which can be nested inside other expressions. Line-oriented features <br>like these don't work well as expressions, because you normally place <br>several expressions on a single line, nesting them inside one another. <br>Thus, these features may be awkward to use in any but the simplest <br>ways.<br><br>-- <br>Brent Royal-Gordon<br>Architechies<br><br></body></html>