[swift-evolution] multi-line string literals.

Tue Apr 26 08:37:22 CDT 2016

Please allow me to add my 2 cents. How I think about multi-line feature: it 
should allow to paste any text as-is, which will have no any special 
letters/symbols in it. Such text should be copied to variable *exactly* as 
typed inside source file.

I want to be able to have in source file exactly this text, without any 
wrapping of "disallowed" symbols :

<?xml version="1.0"?>
<catalog>
	<book id="myid" empty="">
		<author>myAuthor</author>
		<title>myTitle \tutorial 1\(edition 2)</title>
	</book>
</catalog>

(please note this "\tuttorial" and "\(edition" )

So, I suggest to start such multi line with "\ and have " as 
end-of-multiline marker:

var xml = "\
<?xml version="1.0"?>
<catalog>
	<book id="myid" empty="">
		<author>myAuthor</author>
		<title>myTitle \tutorial 1\(edition 2)</title>
	</book>
</catalog>
"

Pros:
* text as-is, you can have " \ \\ \t \( etc symbols
* var xml = "  - clearly seems like start of string, all the lines looks 
like inside one string
* "\  - says that here is some special case, as we usually need some symbol 
after \ to have special character like \t or \n
* ends with "  - clearly see that here is an end of string (probably "; 
should be required here.)

Cons:
* if we need tabs inside our 'xml' variable - we need to keep them in 
source file
* spaces at the end of each line could be trimmed by editor
* line with only " symbol is not allowed inside mutli-line string - it will 
terminate the string.

But the cons could be solved (if you need this) by custom markers you can 
use to replace later in 'xml' variable like:
var multiline = "\
#tab<folder>
#tab#tab<file>...</file>
#tab#tab<file>...</file>
#tab</folder>
"
multiline.replace("#tab", to:"\t")

On 26.04.2016 8:53, Michael Peternell via swift-evolution wrote:
> """Just in my opinion: having to start each line with a particular token
> kinda defeats the purpose of multiline string literals. "can't we just
> continue" "the literal on the next line anyways," "like in C?" "or maybe
> the "+ "at the end of the line can be"+ "optimized away?" """
>
> What is wrong with just using """ as a delimiter? Except that maybe
> there are other languages which use this already. You can copy&paste
> whole XML snippets into such a thing. It's also good for usage
> instructions in a command line tool, and I think everyone will
> understand what it means. Is it a design goal to do something completely
> new? Or are you just unhappy with all existing multi-line string literal
> syntaxes?
 >
> -Michael (who would be happy with Perl Heredoc-Syntax as well)
>
>> Am 26.04.2016 um 01:00 schrieb ted van gaalen via swift-evolution
>> <swift-evolution at swift.org>:
>>
>> possible improvement, one could allow leading spaces before the "data
>> line token" thus enabling indentation, like so { let str =
>> \\dataaaaaaaaaahgdfhhfdxfg cvcsffggcfg \\c jggjvhfh fhffhfgxfxgdgfhgj
>> jvhhfhfhcgxgc . . }
>>
>> TedvG
>>
>> On 25 Apr 2016, at 20:47, Ted F.A. van Gaalen <tedvgiosdev at gmail.com>
>> wrote:
>>
>>> This could be a simple solution:
>>>
>>> Starting each line with a special token.
>>>
>>> In the example here it is the \\  double-backslash . when the \\
>>> appears in the first two columns of a source line, this tells the
>>> compiler that it is a data line and that more might follow. the last
>>> line starting with \\ completes the data entry.
>>>
>>> Here is an example of a string declaration with some XML (no escape
>>> sequences needed for “) Of course it could be anything other kind of
>>> textual data as well.
>>>
>>> let  str = \\<!DOCTYPE html> \\<html> \\<body> \\ \\<h1>W3Schools
>>> Internal Note</h1>\n \\<div> \\<b>To:</b> <span
>>> id="to"></span><br>\n \\<b>From:</b> <span id="from"></span><br>\n
>>> \\<b>Message:</b> <span id="message"></span> \\</div> \\\n
>>> \\<script> \\var txt, parser, xmlDoc; \\txt = "<note>" +
>>> \\"<to>Tove</to>" + \\etc. this is the last data line.
>>>
>>>
>>> Conditions:
>>>
>>> - Every line starting with \\ in first and second column of the line
>>>  is  treated as a data line. - All characters behind the \\ are
>>> regarded as data, thus note that: - the “ is not regarded as a
>>> string delimiter - the // chars and whatever follows it are
>>> interpreted as data on such a line, not as comment. -  \\  within
>>> the data itself are treated as data e.g. this line is valid: \\There
>>> \\ are three backslashes (as data) in this line \\\\ today. \\ the
>>> above data line is empty but is allowed.
>>>
>>> - Leading and embedded spaces are respected. - Tabs, Linefeeds etc.
>>> can be inserted the usual way using \t \n etc. - trailing spaces and
>>> line terminators cr lf are ignored, filtered out.
>>>
>>> let dutchNumbers = \\ een twee drie vier vijf
>>>
>>> \\ zes zeven acht negen tien \\these two data lines are orphans,
>>>
>>> Blank lines or other Swift statement lines in-between breaks a set
>>> of \\ data lines
>>>
>>>
>>> All \\ lines together are treated as one single string literal and
>>> may occur everywhere where “normal” string literals are allowed.
>>>
>>> // E.g. this if statement would be correct: // Yes, this would be
>>> legal but doesn’t look so great: Indentation not possible here if
>>> cars == \\Ford \\ Delorean \\ Chevrolet { doSomething() }
>>>
>>> An array with 2 string elements:
>>>
>>> var ar = [ \\sdkdslkdslkdsldkshfkjdljfsdljkfdshjklfd dioioioioio
>>> \n\nsljkf sdflkf dsl;dfsk sdlfk dfsfkds \\ sdkdfkdfldkfd fdfldk
>>> fdlkfd jkfds  hjklfd dsljkf sdflkf dsl;dfsk sdlfk dfsfkds , \\There
>>> are many ships in the ha \\rbour that are soon sailing away. ]
>>>
>>>
>>> I also thought about using “”  as token, but this would be
>>> interpreted as an empty string. or “”” but this is an empty string
>>> followed by an unclosed string literal.
>>>
>>> Should be relatively easy to implement? What y’all think?
>>>
>>>
>>> Kind Regards TedvG
>> _______________________________________________ swift-evolution
>> mailing list swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________ swift-evolution mailing
> list swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>