[swift-evolution] multi-line string literals

[Kametrixom Tikara]

Why don't we just use the back ticks  " ` ", making it similar to markup:

let code =
```
main = interact id
```

I believe nobody would ever want to put three back ticks inside a string.

Also I think one doesn't actually want/need interpolation, because every char should be the same in the string as it appears in the code. We can do something like instead (just concat the strings together):

let myString = "Hello!"
let code =
```
main = p "``` + myString + ```"
  where p = putStrLn
```

(Shorter would be to drop the "+" with some compiler magic, but that's meh)

I don't think the use for such literals isn't too common so that it's not necessary to provide string interpolation just for these few cases.


> On 11 Dec 2015, at 18:29, Travis Tilley via swift-evolution <swift-evolution at swift.org> wrote:
> 
> My updated thoughts, after some feedback about JSON and escaping, would be to wrap an escaped multi-line literal with triple quotes, and to wrap an unescaped multi-line literal with single quotes... Then, to make the overall syntax consistent, to do the same for single-line strings. In either case, quotes of any kind other than a triple quote would not need to be escaped in a multi-line string literal. So:
> 
> 
> let foo = """
>   hell yeah, escapes! \n\n
>   \(sound) like a "\(animal)"
>   this is another completely random line
> """
> 
> Would have a foo variable containing (note the stripped indentation, as that seems to be the popular request in this thread):
>> hell yeah, escapes!
>> 
>> moo like a "cow"
>> this is another completely random line
> 
> But if wrapped by ''' then none of the interpolation or escape processing happens (and quotes still don't need to be escaped).
> 
> Come to think of it, I don't see why a ''' syntax would -have- to be multi-line. No reason why '''/"moo"/"cow"/g''' should be invalid from a technical perspective. (note that swift has no native regex literal, though you can create your own and this triple single-quote syntax might make that less painful)
> 
> 
> - Travis Tilley
> 
> 
>> On Fri, Dec 11, 2015 at 12:01 PM, John Siracusa via swift-evolution <swift-evolution at swift.org> wrote:
>> Sorry about the lack of a subject on this message originally. I was replying to the email digest and forgot to add one. It should be part of the "multi-line string literals" thread.
>> 
>> -John
>> 
>>> On Fri, Dec 11, 2015 at 11:52 AM, John Siracusa <siracusa at gmail.com> wrote:
>>> 
>>> Chris Lattner wrote:
>>>> When introducing a feature like this, I think it would be useful to survey a range of popular languages (and yes, even perl ;-) to understand what facilities they provide and why (i.e. what problems they are solving) and synthesize a good swift design that can solve the same problems with a hopefully simple approach.
>>> 
>>> Travis Tilley wrote:
>>>> ​Perl and Erlang are unique in that valid code in either language looks essentially like line noise. I'd rather take inspiration from languages like ruby, python, and elixir.​
>>> 
>>> Jokes aside, the ability to choose delimiters for strings and other language constructs that surround some value is a huge boon to code readability.
>>> 
>>> For example, RegExp literals in JavaScript:
>>> 
>>> var regex = /^\/usr\/local\//; // gross
>>> 
>>> An even simpler example, which applies to many languages: a string literal that contains all of your possible string delimiters within it. This is not an exotic thing in English.
>>> 
>>> message = "\"I don't like this,\" she said."; // nope
>>> message = '"I don\'t like this," she said.';  // still nope
>>> 
>>> Then, of course, there's your escape character itself:
>>> 
>>> escapes = "Some escapes: \\n, \\t, \\a"; // sigh
>>> 
>>> There are many time-tested solutions to these syntactic/cosmetic problems. 
>>> 
>>> * Different delimiters with different interpolation rules (e.g., single quotes not honoring any backslash escapes and not doing variable interpolation)
>>> 
>>> * Matched-pair delimiters that don't require anything to be escaped as long as the delimiters are absent or matched within the string. (These alone solve a huge range of problems.)
>>> 
>>> * Heredocs for long literals where you get to pick the end token.
>>> 
>>> * Heredocs modified by delimiters around the end token to control interpolation within the long literal.
>>> 
>>> Which language looks like line noise now?
>>> 
>>> 	$messasge = q("I can't believe how nice this is," she said (quietly).);
>>> 
>>> 	$regex = qr(^/usr/local/);
>>> 
>>> 	$escapes = 'Some escapes: \n, \t, \a';
>>> 
>>> My take: once you use a language where you pretty much never have to backslash-escape a character you can easily type to get it into a string, it's really hard to go back. 
>>> 
>>> -John
>> 
>>  
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151212/6a8ecfc3/attachment.html>