[swift-evolution] multi-line string literals.

[ted van gaalen]

Hi Michael
also inline

> On 26 Apr 2016, at 22:05, Michael Peternell <michael.peternell at gmx.at> wrote:
> 
> Comments inline.
> 
>> Am 26.04.2016 um 15:32 schrieb Ted F.A. van Gaalen <tedvgiosdev at gmail.com>:
>> 
>> Hi Michael
>> 
>> What happens if a delimiter in this case: “”” 
>> occurs embedded in the data?   like  so (two times here):
> 
> that's a problem you always have.
It is not a problem with the "data line" method that I suggest...
> And I think pasting a few lines of text is a (much) more common use case than wanting to have a string literal that contains """ in it.
..all you have to do is paste your few lines of text an put \@ in front of each line...
** (see further in text)

If copying larger texts, it might be better to use a resource (file) instead of
hard coding all that data into a multi-line string. 

 

> I have never needed a string literal that contained """, and as long as you don't create a parser for a language that wants to parse such literals, the use cases are very rare IMO. 
Swift is a general purpose language used for making many different applications..


> Furthermore, if the string interpolation and escape sequences are enabled, I can answer this directly: you write """some text
> some text. Here you have 3 double quotes: ""\" and here again \"""
> """; you can just put a backslash before one of the offending double quotes.
> 
then you would have to change all the " in say an Xml group of lines.
> I think starting each line with \\ is really ugly,
Ok, but that's just a matter of personal taste...
I'll gladly give up some esthetics for better functionality.
> and I wouldn't consider this a true "multi-line string literal". Because instead of writing
> 
> \\bla bla
> \\bla bla
> 
> I'd rather write
> 
this:
> "bla bla\n"
> "bla bla"
already exists with +  ... +
but then you have to add \n as well and use escape \" all the time.
e.g. when coding Html lines with parameters.
>> 
>> “””
>> dfksposdkj dslkd s hfdslk   dskdslk  lskd sk aaasd
>> lfsdlks dslksd sdlk sdlksd  “””  fskfsdalkfsd  “”” fdjf dkjfds  
>> “”"
>> 
>> Having a particular token at the start of a line (or after  leading space(s) ) to define a data line 
>> allows us to use *all* available characters behind it.  
>> 
>> Actually after further thinking, I assume that 1 token is not enough, perhaps there should be two tokens e.g.
>> 
>>  \\ ……………...   to process  escaped chars, like \… and \(item),  
>>                the same way as with normal Swift string literals
>> 
>>  \@………….   to take all characters as is without conversion?    
>> 
>> 
>> Examples:
>> 1.
>> let someText = 
>> \\There are \t \t  \(nrofboxes) boxes avai
>> \\lable.
>> converts to:
>> "There are             12 boxes available."
> 
> really? so I have to write \n if I want to have a newline?
> 
**
Yes, because here, \\ is used instead of other suggested token \@ 
but respecting source-file-linefeeds could perhaps be an option
when using \@ ?

>> 
>> 2.
>> 
>> let someText = 
>> \@There are \t \t  \(nrofboxes) boxes avai
>> \@able.
>> String taken as is, nothing is converted:
>> "There are \t \t  \(nrofboxes) boxes available."
>> 
>> Of course one could choose other tokens than \\ and \@
>> they just looked convenient to me...
>> 
>> TedvG
>> 
>> 
>>> On 26.04.2016, at 07:53, Michael Peternell <michael.peternell at gmx.at> wrote:
>>> 
>>> """Just in my opinion:
>>> having to start each line with a particular token kinda defeats the purpose of multiline string literals.
>> Why? 
> 
> because IMHO the purpose of multiline string literals *is* that you can copy&paste multiple lines of text directly into the editor? If I call \\literals a 'multi-line literal', I can call "normal strings" multiline too, can't I?
> 
> What makes
>    \\this
>    \\string
> a 'multiline string literal'
>    "and this "
>    "string"
> not? (What is the definition of a "multiline string literal"?)
> 
> -Michael
> 
Regards, TedvG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160427/88b34675/attachment-0001.html>