[swift-evolution] multi-line string literals.

Michael Peternell michael.peternell at gmx.at
Tue Apr 26 00:53:49 CDT 2016


"""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



More information about the swift-evolution mailing list