[swift-evolution] multi-line string literals.

[L. Mihalkovic]

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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution