Would you all be so kind to take a look at what I suggested 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"?> "<catalog> " <book id="bk101" empty=""> " <author>\(author)</author> " </book> "</catalog> ``` 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 literal. 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 ways. -- Brent Royal-Gordon Architechies |
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
