I have a simple working prototype where the following just works Let v = _" "key": "value" "_
I am working on adding Let v = /* this is a template */ _" "key": "value" "_ Let v @string_literal(json) = /* this is a template */ _" "key": "value" "_ This strikes me as far less intrusive on the current compiler structure Regards (From mobile) On May 7, 2016, at 3:48 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.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 >> and >> \\ 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 >> here. > > 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution