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