[swift-evolution] multi-line string literals.

[Ted F.A. van Gaalen]

>> 	let xml = _"<?xml version="1.0"?>
>> 	            "<catalog>
>> 	            " <book id="bk101" empty="">
>> 	            "     <author>\(author)</author>
>> 	            " </book>
>> 	            "</catalog>”_

If I am reading and understanding this correctly:
This solution is still delimiter-sensitive and
breaks if    “_     delimiter is found somewhere within the data,
because it is interpreted as end-of-string.

I wrote already about my solution   
which solves the above deficiency, 
because it does not use delimiters at all.

I have thought it all over and cleaned it up. Here it is again,
hopefully this description is more clear and readable.

Data Line Operators. 

For convenience, I call these \\ and \@ :  “data-line-operators” .
(of course, they are pseudo operators) 
Other two? character combinations for these operators are also possible. 


The  \@  data-line-operator:   
     -  takes character data "as-is” without any conversion.
     -  respects (includes) source-file line terminators.
     -  all spaces in-between and up to the source line's end are included.
     -  comments // are not seen as comments but read as data. 
     -  the \@ on its own (without anything else to the right) is implicitly an empty line.  
   

The  \\   data-line-operator:    
   -  converts escaped chars like \t \n  and \(var) substitution, as with “normal" string literals.
   -  ignores trailing spaces and source-file line terminators.
   -  respects  // comments on the same line and will not include these as data. 
   -  the  \\ on its own is interpreted as \n (line feed)  thus (optionally) eliminating the 
      need for  \n usage. 

Both operators allow 0…n spaces/tabs on its left side, 
thus indentation is supported.

Example 1. The \@ operator: 

	 // 1.  multi-line string literal with data lines as is. 
         // It loads each line (part) up to and including the source-file-line- end:
         // you can use all available characters without problems, 
         // even \\ and \@  thus allowing you to nest e.g. Swift statements...  
        
         let xml =                                                    
                     \@<?xml version="1.0"?>
	             \@  <catalog>
	             \@    <book id="bk101" empty=“”>      // this is not regarded as a comment.
	             \@       <author>//¯\"_(ツ)_//</author>
	             \@    </book>
                     \@  </catalog> 
 

   Example 2, The \\ operator: 
   // Multi-line string literal with data lines with \n \t etc. respected: 

         var str =
                     \\This is line one.\nThis is line two, with a few \t\t\t tabs in it...
                     \\                                            
                     \\This is line three: there are \(cars)                 // this is a comment.
                     \\ waiting in the garage. This is still line three

 The first \@ or \\ must be on a new line, this is an error:

     let str =  /@data data data data…...
     /@data………….


A block of \@  or \\ lines must be contiguous: with no other lines in-between.
An empty line or other source line implicitly ends the 
\\ or \@ block of lines. There is no terminator. 

 \@ and \\  lines can be mixed together in the same block.
 Should this be allowed? 



Imho even easier to understand and simple.

I could make a proposal for this later in May.

@Vladimir: sorry I didn’t respond directly on your email
You’re right. Our ideas about this have some similarity? 
Your point: 
   "and I believe I can prove we need some start-of-line marker)” :
 I think so too, that’s why I suggest the \\ and \@ data-line-operators. 
as described here.  

Too busy, packing things to move to www.speyer.de
I will read swift-evolution, but will probably not
respond until after the 12th of May or so.

Although away, some feedback would be nice, thank you.

Kind Regards
TedvG





Fri, 29 Apr 2016 08:20:34 -0600 Erica Sadun wrote: 

>> On Apr 28, 2016, at 4:52 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> Did you ever really use multiline string literals before?
>> 
>> Yes. I used Perl in the CGI script era. Believe me, I have used every quoting syntax it supports extensively, including `'` strings, `"` strings, `q` strings, `qq` strings, and heredocs. This proposal is educated by knowledge of their foibles.
>> 
>> As outlined in the "Future directions for string literals in general" section, I believe alternate delimiters (so you can embed quotes) are a separate feature and should be handled in a separate proposal. Once both features are available, they can be combined. For instance, using the `_"foo"_` syntax I sketch there for alternate delimiters, you could say:
>> 
>> 	let xml = _"<?xml version="1.0"?>
>> 	            "<catalog>
>> 	            " <book id="bk101" empty="">
>> 	            "     <author>\(author)</author>
>> 	            " </book>
>> 	            "</catalog>"_
> 
> Other than the underscores (I'm not sold on them but I could live with them), this is my favorite approach:
> 
> * It supports indented left-hand alignment, which is an important to me for readability
> * It avoids painful `\n"+` RHS constructions
                                             ^ what are RHS constructions ? 
> * It's easy to scan and understand
> * It's simple and harmonious
                            
> 
> — E


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160430/0d39b311/attachment.html>