# multi-line string literals

**URL:** <https://forums.swift.org/t/multi-line-string-literals/441>\
**Category:** Discussion\
**Created:** [December 11, 2015, 5:01pm UTC](https://forums.swift.org/t/multi-line-string-literals/441 "2015-12-11T17:01:52Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![siracusa](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/siracusa/32/36300_2.png) [@siracusa](https://forums.swift.org/u/siracusa)\
**Post date:** [December 11, 2015, 5:01pm UTC](https://forums.swift.org/t/multi-line-string-literals/441/1 "2015-12-11T17:01:52Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Travis\_Tilley](https://avatars.discourse-cdn.com/v4/letter/t/43a26b/32.png) [@Travis\_Tilley](https://forums.swift.org/u/Travis_Tilley)\
**Post date:** [December 11, 2015, 5:29pm UTC](https://forums.swift.org/t/multi-line-string-literals/441/2 "2015-12-11T17:29:56Z")

</div>

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 = """  
&nbsp;&nbsp;hell yeah, escapes! \n\n  
&nbsp;&nbsp;\(sound) like a "\(animal)"  
&nbsp;&nbsp;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@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@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@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Kametrixom\_Tikara](https://avatars.discourse-cdn.com/v4/letter/k/7c8e57/32.png) [@Kametrixom\_Tikara](https://forums.swift.org/u/Kametrixom_Tikara)\
**Post date:** [December 11, 2015, 11:08pm UTC](https://forums.swift.org/t/multi-line-string-literals/441/3 "2015-12-11T23:08:06Z")

</div>

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

let code =

```swift
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 =

````swift
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@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 = """  
> > &nbsp;&nbsp;hell yeah, escapes! \n\n  
> > &nbsp;&nbsp;\(sound) like a "\(animal)"  
> > &nbsp;&nbsp;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@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@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?
> > > > 
> > > > &nbsp;&nbsp;$messasge = q("I can't believe how nice this is," she said (quietly).);
> > > > 
> > > > &nbsp;&nbsp;$regex = qr(^/usr/local/);
> > > > 
> > > > &nbsp;&nbsp;$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@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![jtbandes](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jtbandes/32/463_2.png) [@jtbandes](https://forums.swift.org/u/jtbandes)\
**Post date:** [December 11, 2015, 11:26pm UTC](https://forums.swift.org/t/multi-line-string-literals/441/4 "2015-12-11T23:26:45Z")

</div>

Lua has an interesting solution to this, where the delimiters can be  
extended as much as you want, to avoid conflicts with string content.

[[This]] and [=[This]=] are allowed, and [===[ These [[ are part of the  
string ]], since they don't conflict with the outer delimiters. ]===]

> <https://stackoverflow.com/questions/21246668/whats-the-point-of-nesting-brackets-in-lua>

Jacob

> **···**
>
> On Fri, Dec 11, 2015 at 3:21 PM, Travis Tilley via swift-evolution \< swift-evolution@swift.org\> wrote:
> 
> > If you're writing a block of github flavored markdown, I can absolutely  
> > see someone wanting to write out 3 backticks in a multi-line string  
> > literal. ::shrug::
> > 
> > On Fri, Dec 11, 2015 at 6:08 PM, Kametrixom Tikara \<kametrixom@icloud.com\> \> wrote:
> > 
> > > Why don't we just use the back ticks " ` ", making it similar to markup:
> > > 
> > > let code =
> > > 
> > > ```swift
> > > 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 =
> > > 
> > > ````swift
> > > 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@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 = """  
> > > &nbsp;&nbsp;hell yeah, escapes! \n\n  
> > > &nbsp;&nbsp;\(sound) like a "\(animal)"  
> > > &nbsp;&nbsp;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@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@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@swift.org  
> > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Drew\_Crawford1](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/drew_crawford1/32/11959_2.png) [@Drew\_Crawford1](https://forums.swift.org/u/Drew_Crawford1)\
**Post date:** [December 11, 2015, 11:26pm UTC](https://forums.swift.org/t/multi-line-string-literals/441/5 "2015-12-11T23:26:37Z")

</div>

That's an interesting idea! What about """ for escaped strings and ``` for unescaped literal strings?

The latter is intuitive for me for preformatted text (with JSON et al are), and Swift in fact uses Markdown for doc comments, so we assume some familiarity from the developer.

> **···**
>
> > On Dec 11, 2015, at 5:21 PM, Travis Tilley via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > If you're writing a block of github flavored markdown, I can absolutely see someone wanting to write out 3 backticks in a multi-line string literal. ::shrug::
> > 
> > On Fri, Dec 11, 2015 at 6:08 PM, Kametrixom Tikara \<kametrixom@icloud.com \<mailto:kametrixom@icloud.com\>\> wrote:  
> > Why don't we just use the back ticks " ` ", making it similar to markup:
> > 
> > let code =
> > 
> > ```swift
> > 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 =
> > 
> > ````swift
> > 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@swift.org \<mailto:swift-evolution@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 = """  
> > > &nbsp;&nbsp;hell yeah, escapes! \n\n  
> > > &nbsp;&nbsp;\(sound) like a "\(animal)"  
> > > &nbsp;&nbsp;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@swift.org \<mailto:swift-evolution@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@gmail.com \<mailto:siracusa@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?
> > > 
> > > &nbsp;&nbsp;$messasge = q("I can't believe how nice this is," she said (quietly).);
> > > 
> > > &nbsp;&nbsp;$regex = qr(^/usr/local/);
> > > 
> > > &nbsp;&nbsp;$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@swift.org \<mailto:swift-evolution@swift.org\>  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
> > 
> > swift-evolution mailing list  
> > swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Travis\_Tilley](https://avatars.discourse-cdn.com/v4/letter/t/43a26b/32.png) [@Travis\_Tilley](https://forums.swift.org/u/Travis_Tilley)\
**Post date:** [December 11, 2015, 11:21pm UTC](https://forums.swift.org/t/multi-line-string-literals/441/6 "2015-12-11T23:21:46Z")

</div>

If you're writing a block of github flavored markdown, I can absolutely see  
someone wanting to write out 3 backticks in a multi-line string literal.  
::shrug::

> **···**
>
> On Fri, Dec 11, 2015 at 6:08 PM, Kametrixom Tikara \<kametrixom@icloud.com\> wrote:
> 
> > Why don't we just use the back ticks " ` ", making it similar to markup:
> > 
> > let code =
> > 
> > ```swift
> > 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 =
> > 
> > ````swift
> > 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@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 = """  
> > &nbsp;&nbsp;hell yeah, escapes! \n\n  
> > &nbsp;&nbsp;\(sound) like a "\(animal)"  
> > &nbsp;&nbsp;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@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@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@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Travis\_Tilley](https://avatars.discourse-cdn.com/v4/letter/t/43a26b/32.png) [@Travis\_Tilley](https://forums.swift.org/u/Travis_Tilley)\
**Post date:** [December 11, 2015, 11:35pm UTC](https://forums.swift.org/t/multi-line-string-literals/441/7 "2015-12-11T23:35:04Z")

</div>

Fair enough point. But wouldn't we still want indentation erasure which  
would be counter-intuitive for what we expect from triple backticks?  
like... a block of json defined in the middle of a function, this having  
maybe two levels of indentation to be erased.

> **···**
>
> On Fri, Dec 11, 2015 at 6:26 PM, Drew Crawford \<drew@sealedabstract.com\> wrote:
> 
> > That's an interesting idea! What about """ for escaped strings and ```  
> > for unescaped literal strings?
> > 
> > The latter is intuitive for me for preformatted text (with JSON et al  
> > are), and Swift in fact uses Markdown for doc comments, so we assume some  
> > familiarity from the developer.

---

<div class="post-metadata">

**Author:** ![Kametrixom\_Tikara](https://avatars.discourse-cdn.com/v4/letter/k/7c8e57/32.png) [@Kametrixom\_Tikara](https://forums.swift.org/u/Kametrixom_Tikara)\
**Post date:** [December 11, 2015, 11:28pm UTC](https://forums.swift.org/t/multi-line-string-literals/441/8 "2015-12-11T23:28:25Z")

</div>

Yeah I know it's not pleasant to write, but we don't actually want to write such string literals often, because it's actually just a hard coded string without any dynamic behaviour. Also the three back ticks is already a known syntax for most (GitHub) people.

> **···**
>
> > On 12 Dec 2015, at 00:21, Travis Tilley \<ttilley@gmail.com\> wrote:
> > 
> > If you're writing a block of github flavored markdown, I can absolutely see someone wanting to write out 3 backticks in a multi-line string literal. ::shrug::
> > 
> > > On Fri, Dec 11, 2015 at 6:08 PM, Kametrixom Tikara \<kametrixom@icloud.com\> wrote:  
> > > Why don't we just use the back ticks " ` ", making it similar to markup:
> > > 
> > > let code =
> > > 
> > > ```swift
> > > 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 =
> > > 
> > > ````swift
> > > 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@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 = """  
> > > > &nbsp;&nbsp;hell yeah, escapes! \n\n  
> > > > &nbsp;&nbsp;\(sound) like a "\(animal)"  
> > > > &nbsp;&nbsp;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@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@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?
> > > > > > 
> > > > > > &nbsp;&nbsp;$messasge = q("I can't believe how nice this is," she said (quietly).);
> > > > > > 
> > > > > > &nbsp;&nbsp;$regex = qr(^/usr/local/);
> > > > > > 
> > > > > > &nbsp;&nbsp;$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@swift.org  
> > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > > > 
> > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > > swift-evolution mailing list  
> > > > swift-evolution@swift.org  
> > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Kametrixom\_Tikara](https://avatars.discourse-cdn.com/v4/letter/k/7c8e57/32.png) [@Kametrixom\_Tikara](https://forums.swift.org/u/Kametrixom_Tikara)\
**Post date:** [December 11, 2015, 11:48pm UTC](https://forums.swift.org/t/multi-line-string-literals/441/9 "2015-12-11T23:48:39Z")

</div>

I think it can just work like this:

struct Test {  
&nbsp;&nbsp;&nbsp;&nbsp;func hi() {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;let json =  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;``` // Indentation to the left of the back ticks gets erased and nothing more  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Hello": 3  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;```  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;let str =  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;```  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"This is a string"  
&nbsp;&nbsp;&nbsp;&nbsp;``` // Compiler error: Back ticks not aligned  
&nbsp;&nbsp;&nbsp;&nbsp;  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;let hs =  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;```  
&nbsp;&nbsp;&nbsp;&nbsp;main = interact id // Compiler error: too little indentation  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;```  
&nbsp;&nbsp;&nbsp;&nbsp;}  
}

By just not supporting more complex indentation erasure, we can avoid potential confusion.

> **···**
>
> > On 12 Dec 2015, at 00:35, Travis Tilley \<ttilley@gmail.com\> wrote:
> > 
> > Fair enough point. But wouldn't we still want indentation erasure which would be counter-intuitive for what we expect from triple backticks? like... a block of json defined in the middle of a function, this having maybe two levels of indentation to be erased.
> > 
> > On Fri, Dec 11, 2015 at 6:26 PM, Drew Crawford \<drew@sealedabstract.com \<mailto:drew@sealedabstract.com\>\> wrote:  
> > That's an interesting idea! What about """ for escaped strings and ``` for unescaped literal strings?
> > 
> > The latter is intuitive for me for preformatted text (with JSON et al are), and Swift in fact uses Markdown for doc comments, so we assume some familiarity from the developer.

---

<div class="post-metadata">

**Author:** ![Travis\_Tilley](https://avatars.discourse-cdn.com/v4/letter/t/43a26b/32.png) [@Travis\_Tilley](https://forums.swift.org/u/Travis_Tilley)\
**Post date:** [December 12, 2015, 12:03am UTC](https://forums.swift.org/t/multi-line-string-literals/441/10 "2015-12-12T00:03:49Z")

</div>

Fair enough. Plus if Chris Lattner has any strong opinions about the  
behavior of single quotes, which might be the case given the existing code  
for handling them in Lexer.cpp, backticks are a damn good alternative. I'd  
still like to wait to hear back from him or someone else on the core team  
about that one.

-Travis Tilley

> **···**
>
> On Fri, Dec 11, 2015 at 6:48 PM, Kametrixom Tikara \<kametrixom@icloud.com\> wrote:
> 
> > I think it can just work like this:
> > 
> > struct Test {  
> > &nbsp;&nbsp;&nbsp;&nbsp;func hi() {  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;let json =  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;``` // Indentation to the left of the back ticks gets  
> > erased and nothing more  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Hello": 3  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;```
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;let str =  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;```  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"This is a string"  
> > &nbsp;&nbsp;&nbsp;&nbsp;``` // Compiler error: Back ticks not aligned
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;let hs =  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;```  
> > &nbsp;&nbsp;&nbsp;&nbsp;main = interact id // Compiler error: too little indentation  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;```  
> > &nbsp;&nbsp;&nbsp;&nbsp;}  
> > }
> > 
> > By just not supporting more complex indentation erasure, we can avoid  
> > potential confusion.
> > 
> > On 12 Dec 2015, at 00:35, Travis Tilley \<ttilley@gmail.com\> wrote:
> > 
> > Fair enough point. But wouldn't we still want indentation erasure which  
> > would be counter-intuitive for what we expect from triple backticks?  
> > like... a block of json defined in the middle of a function, this having  
> > maybe two levels of indentation to be erased.
> > 
> > On Fri, Dec 11, 2015 at 6:26 PM, Drew Crawford \<drew@sealedabstract.com\> \> wrote:
> > 
> > > That's an interesting idea! What about """ for escaped strings and ```  
> > > for unescaped literal strings?
> > > 
> > > The latter is intuitive for me for preformatted text (with JSON et al  
> > > are), and Swift in fact uses Markdown for doc comments, so we assume some  
> > > familiarity from the developer.

---

<div class="post-metadata">

**Author:** ![Jason\_Dusek](https://avatars.discourse-cdn.com/v4/letter/j/6f9a4e/32.png) [@Jason\_Dusek](https://forums.swift.org/u/Jason_Dusek)\
**Post date:** [December 12, 2015, 12:43am UTC](https://forums.swift.org/t/multi-line-string-literals/441/11 "2015-12-12T00:43:24Z")

</div>

I think it can just work like this:

> struct Test {  
> &nbsp;&nbsp;&nbsp;&nbsp;func hi() {  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;let json =  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;``` // Indentation to the left of the back ticks gets  
> erased and nothing more  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Hello": 3  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;```
> 
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;let str =  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;```  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"This is a string"  
> &nbsp;&nbsp;&nbsp;&nbsp;``` // Compiler error: Back ticks not aligned
> 
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;let hs =  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;```  
> &nbsp;&nbsp;&nbsp;&nbsp;main = interact id // Compiler error: too little indentation  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;```  
> &nbsp;&nbsp;&nbsp;&nbsp;}  
> }

By just not supporting more complex indentation erasure, we can avoid

> potential confusion.

I support the triple backticks — they seem more distinct and avoid the  
double/single quote controversy (and ambiguity).

One use case for a slightly richer approach to indentation erasure — one  
that I encounter every day — is inline SQL. If it’s 10 lines or more, it  
should probably find expression as a VIEW or stored procedure; but queries  
like this are not unusual:

func findMentions(account: String) -\> Array\<String\> {  
&nbsp;&nbsp;&nbsp;&nbsp;let db = databaseFactory().findDatabase()  
&nbsp;&nbsp;&nbsp;&nbsp;let q = `​``SELECT array\_agg(mentioner.id)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;FROM account  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;JOIN mention ON (account.id = mentioned)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;JOIN account AS mentioner ON (mentioner.id = mentioner)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;WHERE account.handle = :1  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ORDER BY timestamp DESC  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;LIMIT 1`​``

&nbsp;&nbsp;&nbsp;&nbsp;return db.query(q).parameterize(account).run()  
}

Moving everything below q seems infelicitous, at best. However, I do see  
the appeal of basing the rule on the position of the backticks.

Best Regards,

Jason Dusek  
​

> **···**
>
> On Fri, 11 Dec 2015 at 15:48 Kametrixom Tikara via swift-evolution swift-evolution@swift.org \<[http://mailto:swift-evolution@swift.org](http://mailto:swift-evolution@swift.org)\> wrote:

---

<div class="post-metadata">

**Author:** ![Travis\_Tilley](https://avatars.discourse-cdn.com/v4/letter/t/43a26b/32.png) [@Travis\_Tilley](https://forums.swift.org/u/Travis_Tilley)\
**Post date:** [December 12, 2015, 6:25am UTC](https://forums.swift.org/t/multi-line-string-literals/441/12 "2015-12-12T06:25:53Z")

</div>

That's another great example that I hadn't even thought of.

- Travis Tilley

> **···**
>
> On Fri, Dec 11, 2015 at 7:43 PM, Jason Dusek \<jason.dusek@gmail.com\> wrote:
> 
> > One use case for a slightly richer approach to indentation erasure — one  
> > that I encounter every day — is inline SQL. If it’s 10 lines or more, it  
> > should probably find expression as a VIEW or stored procedure; but  
> > queries like this are not unusual:
> > 
> > func findMentions(account: String) -\> Array\<String\> {  
> > &nbsp;&nbsp;&nbsp;&nbsp;let db = databaseFactory().findDatabase()  
> > &nbsp;&nbsp;&nbsp;&nbsp;let q = `​``SELECT array\_agg(mentioner.id)  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;FROM account  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;JOIN mention ON (account.id = mentioned)  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;JOIN account AS mentioner ON (mentioner.id = mentioner)  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;WHERE account.handle = :1  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ORDER BY timestamp DESC  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;LIMIT 1`​``
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;return db.query(q).parameterize(account).run()  
> > }
> > 
> > Moving everything below q seems infelicitous, at best. However, I do see  
> > the appeal of basing the rule on the position of the backticks.
> > 
> > Best Regards,
> > 
> > Jason Dusek

---

<div class="post-metadata">

**Author:** ![Chris\_Lattner1](https://avatars.discourse-cdn.com/v4/letter/c/9de053/32.png) [@Chris\_Lattner1](https://forums.swift.org/u/Chris_Lattner1)\
**Post date:** [December 14, 2015, 8:38pm UTC](https://forums.swift.org/t/multi-line-string-literals/441/13 "2015-12-14T20:38:14Z")

</div>

Support for single quoted literals like 'x' was a legacy feature for C-like character literals that we explored before the design of Character went to where it is now. I’d be fine ripping it out and repurposing it.

-Chris

> **···**
>
> > On Dec 11, 2015, at 4:03 PM, Travis Tilley \<ttilley@gmail.com\> wrote:
> > 
> > Fair enough. Plus if Chris Lattner has any strong opinions about the behavior of single quotes, which might be the case given the existing code for handling them in Lexer.cpp, backticks are a damn good alternative. I'd still like to wait to hear back from him or someone else on the core team about that one.

---

<div class="post-metadata">

**Author:** ![Alex\_Gordon](https://avatars.discourse-cdn.com/v4/letter/a/dec6dc/32.png) [@Alex\_Gordon](https://forums.swift.org/u/Alex_Gordon)\
**Post date:** [December 12, 2015, 7:02am UTC](https://forums.swift.org/t/multi-line-string-literals/441/14 "2015-12-12T07:02:18Z")

</div>

What is the reason that normal strings "..." don't support newlines? It's  
not traditionally seen in C-inspired languages, but it's hardly unusual  
outside that sphere[\*]. Ruby and HTML are probably the most common  
examples, but apparently OCaml and Lisps also allow it?

Then we can simply use

1. "..." strings as the verbatim literal, preserving indentation and  
leading newlines as written.

2. """...""" strings as the non-verbatim literal, reducing indentation to  
that of the least indented line, and removing the leading newline if it  
exists.

[\*] As seen earlier  
[http://rigaux.org/language-study/syntax-across-languages.html#StrngMltLine](http://rigaux.org/language-study/syntax-across-languages.html#StrngMltLine)

> **···**
>
> On Sat, Dec 12, 2015 at 6:25 AM, Travis Tilley via swift-evolution \< swift-evolution@swift.org\> wrote:
> 
> > That's another great example that I hadn't even thought of.
> > 
> > - Travis Tilley
> > 
> > On Fri, Dec 11, 2015 at 7:43 PM, Jason Dusek \<jason.dusek@gmail.com\> \> wrote:
> > 
> > > One use case for a slightly richer approach to indentation erasure — one  
> > > that I encounter every day — is inline SQL. If it’s 10 lines or more, it  
> > > should probably find expression as a VIEW or stored procedure; but  
> > > queries like this are not unusual:
> > > 
> > > func findMentions(account: String) -\> Array\<String\> {  
> > > &nbsp;&nbsp;&nbsp;&nbsp;let db = databaseFactory().findDatabase()  
> > > &nbsp;&nbsp;&nbsp;&nbsp;let q = `​``SELECT array\_agg(mentioner.id)  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;FROM account  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;JOIN mention ON (account.id = mentioned)  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;JOIN account AS mentioner ON (mentioner.id = mentioner)  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;WHERE account.handle = :1  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ORDER BY timestamp DESC  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;LIMIT 1`​``
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;return db.query(q).parameterize(account).run()  
> > > }
> > > 
> > > Moving everything below q seems infelicitous, at best. However, I do see  
> > > the appeal of basing the rule on the position of the backticks.
> > > 
> > > Best Regards,
> > > 
> > > Jason Dusek
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Travis\_Tilley](https://avatars.discourse-cdn.com/v4/letter/t/43a26b/32.png) [@Travis\_Tilley](https://forums.swift.org/u/Travis_Tilley)\
**Post date:** [December 12, 2015, 7:25am UTC](https://forums.swift.org/t/multi-line-string-literals/441/15 "2015-12-12T07:25:01Z")

</div>

You'd have to ask Chris Latter and Dmitri Gribenko, who are responsible for  
the lines in Lexer.cpp that prevent it:

22610d5  
\<[https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf&gt;\](https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf&gt;%5C)[image:  
@lattner]substantially improve error recovery for erroneous character and  
stri…  
\<[https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf&gt](https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf&gt);  
lattner \<[https://github.com/lattner&gt](https://github.com/lattner&gt); authored on May 20, 2013  
11471148 // String literals cannot have \n or \r in them.3bee330  
\<[https://github.com/apple/swift/commit/3bee330e5068eb6ed4e825ff77b9e7615758eb47&gt;\](https://github.com/apple/swift/commit/3bee330e5068eb6ed4e825ff77b9e7615758eb47&gt;%5C)[image:  
@gribozavr]Lexer: don't inf loop on an unterminated string literal near EOF  
\<[https://github.com/apple/swift/commit/3bee330e5068eb6ed4e825ff77b9e7615758eb47&gt](https://github.com/apple/swift/commit/3bee330e5068eb6ed4e825ff77b9e7615758eb47&gt);  
gribozavr \<[https://github.com/gribozavr&gt](https://github.com/gribozavr&gt); authored on Aug 22, 2013  
1149 if (\*CurPtr == '\r' || \*CurPtr == '\n' || CurPtr == BufferEnd) {22610d5  
\<[https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf&gt;\](https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf&gt;%5C)[image:  
@lattner]substantially improve error recovery for erroneous character and  
stri…  
\<[https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf&gt](https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf&gt);  
lattner \<[https://github.com/lattner&gt](https://github.com/lattner&gt); authored on May 20, 2013  
1150 diagnose(TokStart, diag::lex\_unterminated\_string);1151 return  
formToken(tok::unknown,  
TokStart);1152 }2f44c00  
\<[https://github.com/apple/swift/commit/2f44c0038c5a53e6ee4bb8f0a0fec4c3bd5d79a2&gt;\](https://github.com/apple/swift/commit/2f44c0038c5a53e6ee4bb8f0a0fec4c3bd5d79a2&gt;%5C)[image:  
@lattner]Initial stab at implementing string literal interpolation for  
simple …  
\<[https://github.com/apple/swift/commit/2f44c0038c5a53e6ee4bb8f0a0fec4c3bd5d79a2&gt](https://github.com/apple/swift/commit/2f44c0038c5a53e6ee4bb8f0a0fec4c3bd5d79a2&gt);  
lattner \<[https://github.com/lattner&gt](https://github.com/lattner&gt); authored on May 4, 2012  
1153

> **···**
>
> On Sat, Dec 12, 2015 at 2:02 AM, Alex Gordon \<alextgordon@gmail.com\> wrote:
> 
> > What is the reason that normal strings "..." don't support newlines? It's  
> > not traditionally seen in C-inspired languages, but it's hardly unusual  
> > outside that sphere[\*]. Ruby and HTML are probably the most common  
> > examples, but apparently OCaml and Lisps also allow it?
> > 
> > Then we can simply use
> > 
> > 1. "..." strings as the verbatim literal, preserving indentation and  
> > leading newlines as written.
> > 
> > 2. """...""" strings as the non-verbatim literal, reducing indentation to  
> > that of the least indented line, and removing the leading newline if it  
> > exists.
> > 
> > [\*] As seen earlier  
> > [syntax across languages (One Big Page)](http://rigaux.org/language-study/syntax-across-languages.html#StrngMltLine)
> > 
> > On Sat, Dec 12, 2015 at 6:25 AM, Travis Tilley via swift-evolution \< \> swift-evolution@swift.org\> wrote:
> > 
> > > That's another great example that I hadn't even thought of.
> > > 
> > > - Travis Tilley
> > > 
> > > On Fri, Dec 11, 2015 at 7:43 PM, Jason Dusek \<jason.dusek@gmail.com\> \>\> wrote:
> > > 
> > > > One use case for a slightly richer approach to indentation erasure — one  
> > > > that I encounter every day — is inline SQL. If it’s 10 lines or more, it  
> > > > should probably find expression as a VIEW or stored procedure; but  
> > > > queries like this are not unusual:
> > > > 
> > > > func findMentions(account: String) -\> Array\<String\> {  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;let db = databaseFactory().findDatabase()  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;let q = `​``SELECT array\_agg(mentioner.id)  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;FROM account  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;JOIN mention ON (account.id = mentioned)  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;JOIN account AS mentioner ON (mentioner.id = mentioner)  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;WHERE account.handle = :1  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ORDER BY timestamp DESC  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;LIMIT 1`​``
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;return db.query(q).parameterize(account).run()  
> > > > }
> > > > 
> > > > Moving everything below q seems infelicitous, at best. However, I do  
> > > > see the appeal of basing the rule on the position of the backticks.
> > > > 
> > > > Best Regards,
> > > > 
> > > > Jason Dusek
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Travis\_Tilley](https://avatars.discourse-cdn.com/v4/letter/t/43a26b/32.png) [@Travis\_Tilley](https://forums.swift.org/u/Travis_Tilley)\
**Post date:** [December 12, 2015, 7:29am UTC](https://forums.swift.org/t/multi-line-string-literals/441/16 "2015-12-12T07:29:08Z")

</div>

Also note that we'd still need raw strings that don't parse escapes but  
still perform indentation erasure. There have been several use cases  
presented in this thread that would require it, so we'd still end up  
needing three string literal styles.

-Travis Tilley

> **···**
>
> On Sat, Dec 12, 2015 at 2:02 AM, Alex Gordon \<alextgordon@gmail.com\> wrote:
> 
> > What is the reason that normal strings "..." don't support newlines? It's  
> > not traditionally seen in C-inspired languages, but it's hardly unusual  
> > outside that sphere[\*]. Ruby and HTML are probably the most common  
> > examples, but apparently OCaml and Lisps also allow it?
> > 
> > Then we can simply use
> > 
> > 1. "..." strings as the verbatim literal, preserving indentation and  
> > leading newlines as written.
> > 
> > 2. """...""" strings as the non-verbatim literal, reducing indentation to  
> > that of the least indented line, and removing the leading newline if it  
> > exists.
> > 
> > [\*] As seen earlier  
> > [syntax across languages (One Big Page)](http://rigaux.org/language-study/syntax-across-languages.html#StrngMltLine)
> > 
> > On Sat, Dec 12, 2015 at 6:25 AM, Travis Tilley via swift-evolution \< \> swift-evolution@swift.org\> wrote:
> > 
> > > That's another great example that I hadn't even thought of.
> > > 
> > > - Travis Tilley
> > > 
> > > On Fri, Dec 11, 2015 at 7:43 PM, Jason Dusek \<jason.dusek@gmail.com\> \>\> wrote:
> > > 
> > > > One use case for a slightly richer approach to indentation erasure — one  
> > > > that I encounter every day — is inline SQL. If it’s 10 lines or more, it  
> > > > should probably find expression as a VIEW or stored procedure; but  
> > > > queries like this are not unusual:
> > > > 
> > > > func findMentions(account: String) -\> Array\<String\> {  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;let db = databaseFactory().findDatabase()  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;let q = `​``SELECT array\_agg(mentioner.id)  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;FROM account  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;JOIN mention ON (account.id = mentioned)  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;JOIN account AS mentioner ON (mentioner.id = mentioner)  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;WHERE account.handle = :1  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ORDER BY timestamp DESC  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;LIMIT 1`​``
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;return db.query(q).parameterize(account).run()  
> > > > }
> > > > 
> > > > Moving everything below q seems infelicitous, at best. However, I do  
> > > > see the appeal of basing the rule on the position of the backticks.
> > > > 
> > > > Best Regards,
> > > > 
> > > > Jason Dusek
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Travis\_Tilley](https://avatars.discourse-cdn.com/v4/letter/t/43a26b/32.png) [@Travis\_Tilley](https://forums.swift.org/u/Travis_Tilley)\
**Post date:** [December 12, 2015, 7:45am UTC](https://forums.swift.org/t/multi-line-string-literals/441/17 "2015-12-12T07:45:23Z")

</div>

Actually, the discussion has definitely pushed me towards the idea of just  
two simple rulesets for enhancing strings:

1) double quotes process escapes while single quotes (or backticks, as  
suggested earlier) do not  
2) triple quotes of either style result in indentation erasure (and no need  
to escape single quotes)

That doesn't mean that single quotes can't also become multi-line like you  
suggest, or that triple quotes must be multi-line as you might just not  
want to escape quotes in a string without changing the behavior of other  
escapes.

I think that keeps things simple, and I really \*really\* like simple.

-Travis Tilley

> **···**
>
> On Sat, Dec 12, 2015 at 2:29 AM, Travis Tilley \<ttilley@gmail.com\> wrote:
> 
> > Also note that we'd still need raw strings that don't parse escapes but  
> > still perform indentation erasure. There have been several use cases  
> > presented in this thread that would require it, so we'd still end up  
> > needing three string literal styles.
> > 
> > -Travis Tilley
> > 
> > On Sat, Dec 12, 2015 at 2:02 AM, Alex Gordon \<alextgordon@gmail.com\> \> wrote:
> > 
> > > What is the reason that normal strings "..." don't support newlines? It's  
> > > not traditionally seen in C-inspired languages, but it's hardly unusual  
> > > outside that sphere[\*]. Ruby and HTML are probably the most common  
> > > examples, but apparently OCaml and Lisps also allow it?
> > > 
> > > Then we can simply use
> > > 
> > > 1. "..." strings as the verbatim literal, preserving indentation and  
> > > leading newlines as written.
> > > 
> > > 2. """...""" strings as the non-verbatim literal, reducing indentation to  
> > > that of the least indented line, and removing the leading newline if it  
> > > exists.
> > > 
> > > [\*] As seen earlier  
> > > [syntax across languages (One Big Page)](http://rigaux.org/language-study/syntax-across-languages.html#StrngMltLine)
> > > 
> > > On Sat, Dec 12, 2015 at 6:25 AM, Travis Tilley via swift-evolution \< \>\> swift-evolution@swift.org\> wrote:
> > > 
> > > > That's another great example that I hadn't even thought of.
> > > > 
> > > > - Travis Tilley
> > > > 
> > > > On Fri, Dec 11, 2015 at 7:43 PM, Jason Dusek \<jason.dusek@gmail.com\> \>\>\> wrote:
> > > > 
> > > > > One use case for a slightly richer approach to indentation erasure —  
> > > > > one that I encounter every day — is inline SQL. If it’s 10 lines or more,  
> > > > > it should probably find expression as a VIEW or stored procedure; but  
> > > > > queries like this are not unusual:
> > > > > 
> > > > > func findMentions(account: String) -\> Array\<String\> {  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;let db = databaseFactory().findDatabase()  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;let q = `​``SELECT array\_agg(mentioner.id)  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;FROM account  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;JOIN mention ON (account.id = mentioned)  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;JOIN account AS mentioner ON (mentioner.id = mentioner)  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;WHERE account.handle = :1  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ORDER BY timestamp DESC  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;LIMIT 1`​``
> > > > > 
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;return db.query(q).parameterize(account).run()  
> > > > > }
> > > > > 
> > > > > Moving everything below q seems infelicitous, at best. However, I do  
> > > > > see the appeal of basing the rule on the position of the backticks.
> > > > > 
> > > > > Best Regards,
> > > > > 
> > > > > Jason Dusek
> > > > 
> > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > > swift-evolution mailing list  
> > > > swift-evolution@swift.org  
> > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Chris\_Lattner1](https://avatars.discourse-cdn.com/v4/letter/c/9de053/32.png) [@Chris\_Lattner1](https://forums.swift.org/u/Chris_Lattner1)\
**Post date:** [December 14, 2015, 8:40pm UTC](https://forums.swift.org/t/multi-line-string-literals/441/18 "2015-12-14T20:40:48Z")

</div>

Among other reasons, Swift’s current behavior makes it straight-forward for the compiler to recover and handle the common error when you’ve forgotten to close a “. If \n’s were allowed in simple string literals, then everything to the end of the file is included in the string, and the only mistake is the missing “. This may seem like a minor thing, but matters a lot in an IDE context where you may have typed

let x = “foo

and just haven’t finished typing, and the entire buffer changes color or something.

-Chris

> **···**
>
> > On Dec 11, 2015, at 11:25 PM, Travis Tilley via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > You'd have to ask Chris Latter and Dmitri Gribenko, who are responsible for the lines in Lexer.cpp that prevent it:
> > 
> > 22610d5 \<[https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf&gt;substantially](https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf&gt;substantially) improve error recovery for erroneous character and stri… \<[https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf&gt](https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf&gt);  
> > lattner \<[https://github.com/lattner&gt](https://github.com/lattner&gt); authored on May 20, 2013  
> > 1147   
> > 1148 // String literals cannot have \n or \r in them.  
> > 3bee330 \<[https://github.com/apple/swift/commit/3bee330e5068eb6ed4e825ff77b9e7615758eb47&gt;Lexer:](https://github.com/apple/swift/commit/3bee330e5068eb6ed4e825ff77b9e7615758eb47&gt;Lexer:) don't inf loop on an unterminated string literal near EOF \<[https://github.com/apple/swift/commit/3bee330e5068eb6ed4e825ff77b9e7615758eb47&gt](https://github.com/apple/swift/commit/3bee330e5068eb6ed4e825ff77b9e7615758eb47&gt);  
> > gribozavr \<[https://github.com/gribozavr&gt](https://github.com/gribozavr&gt); authored on Aug 22, 2013  
> > 1149 if (\*CurPtr == '\r' || \*CurPtr == '\n' || CurPtr == BufferEnd) {  
> > 22610d5 \<[https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf&gt;substantially](https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf&gt;substantially) improve error recovery for erroneous character and stri… \<[https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf&gt](https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf&gt);  
> > lattner \<[https://github.com/lattner&gt](https://github.com/lattner&gt); authored on May 20, 2013  
> > 1150 diagnose(TokStart, diag::lex\_unterminated\_string);  
> > 1151 return formToken(tok::unknown, TokStart);  
> > 1152 }  
> > 2f44c00 \<[https://github.com/apple/swift/commit/2f44c0038c5a53e6ee4bb8f0a0fec4c3bd5d79a2&gt;Initial](https://github.com/apple/swift/commit/2f44c0038c5a53e6ee4bb8f0a0fec4c3bd5d79a2&gt;Initial) stab at implementing string literal interpolation for simple … \<[https://github.com/apple/swift/commit/2f44c0038c5a53e6ee4bb8f0a0fec4c3bd5d79a2&gt](https://github.com/apple/swift/commit/2f44c0038c5a53e6ee4bb8f0a0fec4c3bd5d79a2&gt);  
> > lattner \<[https://github.com/lattner&gt](https://github.com/lattner&gt); authored on May 4, 2012  
> > 1153
> > 
> > On Sat, Dec 12, 2015 at 2:02 AM, Alex Gordon \<alextgordon@gmail.com \<mailto:alextgordon@gmail.com\>\> wrote:  
> > What is the reason that normal strings "..." don't support newlines? It's not traditionally seen in C-inspired languages, but it's hardly unusual outside that sphere[\*]. Ruby and HTML are probably the most common examples, but apparently OCaml and Lisps also allow it?

---

<div class="post-metadata">

**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\
**Post date:** [December 14, 2015, 9:58pm UTC](https://forums.swift.org/t/multi-line-string-literals/441/19 "2015-12-14T21:58:25Z")

</div>

The main issue here is recovery. If you see a newline in a string, is it more likely that the literal is intended to go on for multiple lines, or that the user hasn't finished typing the current line? If you assume the former, your "in a string" state will toggle with the next double-quote you see, and you'll get a cascade of errors down the whole file.

(The general principle: when adding new syntax, it's important to consider not just complete, correct code, but also the possible error and intermediate states that the compiler and SourceKit have to deal with.)

Jordan

> **···**
>
> > On Dec 11, 2015, at 23:02, Alex Gordon via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > What is the reason that normal strings "..." don't support newlines? It's not traditionally seen in C-inspired languages, but it's hardly unusual outside that sphere[\*]. Ruby and HTML are probably the most common examples, but apparently OCaml and Lisps also allow it?
> > 
> > Then we can simply use
> > 
> > 1. "..." strings as the verbatim literal, preserving indentation and leading newlines as written.
> > 
> > 2. """...""" strings as the non-verbatim literal, reducing indentation to that of the least indented line, and removing the leading newline if it exists.
> > 
> > [\*] As seen earlier [syntax across languages (One Big Page)](http://rigaux.org/language-study/syntax-across-languages.html#StrngMltLine)
> > 
> > On Sat, Dec 12, 2015 at 6:25 AM, Travis Tilley via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:  
> > That's another great example that I hadn't even thought of.
> > 
> > - Travis Tilley
> > 
> > On Fri, Dec 11, 2015 at 7:43 PM, Jason Dusek \<jason.dusek@gmail.com \<mailto:jason.dusek@gmail.com\>\> wrote:  
> > One use case for a slightly richer approach to indentation erasure — one that I encounter every day — is inline SQL. If it’s 10 lines or more, it should probably find expression as a VIEW or stored procedure; but queries like this are not unusual:
> > 
> > func findMentions(account: String) -\> Array\<String\> {  
> > &nbsp;&nbsp;&nbsp;&nbsp;let db = databaseFactory().findDatabase()  
> > &nbsp;&nbsp;&nbsp;&nbsp;let q = `​``SELECT array\_agg(mentioner.id \<[http://mentioner.id/&gt;\](http://mentioner.id/&gt;%5C))  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;FROM account  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;JOIN mention ON (account.id \<[http://account.id/&gt](http://account.id/&gt); = mentioned)  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;JOIN account AS mentioner ON (mentioner.id \<[http://mentioner.id/&gt](http://mentioner.id/&gt); = mentioner)  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;WHERE account.handle = :1  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ORDER BY timestamp DESC  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;LIMIT 1`​``
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;return db.query(q).parameterize(account).run()  
> > }  
> > Moving everything below q seems infelicitous, at best. However, I do see the appeal of basing the rule on the position of the backticks.
> > 
> > Best Regards,
> > 
> > Jason Dusek
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Andrey\_Tarantsov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/andrey_tarantsov/32/9434_2.png) [@Andrey\_Tarantsov](https://forums.swift.org/u/Andrey_Tarantsov)\
**Post date:** [December 14, 2015, 7:06pm UTC](https://forums.swift.org/t/multi-line-string-literals/441/20 "2015-12-14T19:06:03Z")

</div>

> What is the reason that normal strings "..." don't support newlines? It's not traditionally seen in C-inspired languages, but it's hardly unusual outside that sphere[\*]. Ruby and HTML are probably the most common examples, but apparently OCaml and Lisps also allow it?

> You'd have to ask Chris Latter and Dmitri Gribenko, who are responsible for the lines in Lexer.cpp that prevent it:

The obvious reason is to catch a missing quote early, with a better error message. I believe it should stay that way, because multiline strings are a lot less widespread.

A.

[Next page](https://forums.swift.org/t/multi-line-string-literals/441.md?page=2)