multi-line string literals


(John Siracusa) #1

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 :wink: 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


(Travis Tilley) #2

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


(Kametrixom Tikara) #3

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jacob Bandes-Storch) #4

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. ]===]

http://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 =

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Drew Crawford) #5

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 =

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@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 = """
  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@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 :wink: 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 <mailto:swift-evolution@swift.org>
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 _______________________________________________

swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Travis Tilley) #6

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 =

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Travis Tilley) #7

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.


(Kametrixom Tikara) #8

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 =

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Kametrixom Tikara) #9

I think it can just work like this:

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

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.


(Travis Tilley) #10

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 {
    func hi() {
        let json =
        ``` // Indentation to the left of the back ticks gets
erased and nothing more
        {
            "Hello": 3
        }
        ```

        let str =
        ```
        "This is a string"
    ``` // Compiler error: Back ticks not aligned

        let hs =
        ```
    main = interact id // Compiler error: too little indentation
        ```
    }
}

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.


(Jason Dusek) #11

I think it can just work like this:

struct Test {
    func hi() {
        let json =
        ``` // Indentation to the left of the back ticks gets
erased and nothing more
        {
            "Hello": 3
        }
        ```

        let str =
        ```
        "This is a string"
    ``` // Compiler error: Back ticks not aligned

        let hs =
        ```
    main = interact id // Compiler error: too little indentation
        ```
    }
}

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> {
    let db = databaseFactory().findDatabase()
    let q = `​``SELECT array_agg(mentioner.id)
                 FROM account
                 JOIN mention ON (account.id = mentioned)
                 JOIN account AS mentioner ON (mentioner.id = mentioner)
                WHERE account.handle = :1
                ORDER BY timestamp DESC
                LIMIT 1`​``

    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> wrote:


(Travis Tilley) #12

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> {
    let db = databaseFactory().findDatabase()
    let q = `​``SELECT array_agg(mentioner.id)
                 FROM account
                 JOIN mention ON (account.id = mentioned)
                 JOIN account AS mentioner ON (mentioner.id = mentioner)
                WHERE account.handle = :1
                ORDER BY timestamp DESC
                LIMIT 1`​``

    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


(Chris Lattner) #13

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.


(Alex Gordon) #14

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

···

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> {
    let db = databaseFactory().findDatabase()
    let q = `​``SELECT array_agg(mentioner.id)
                 FROM account
                 JOIN mention ON (account.id = mentioned)
                 JOIN account AS mentioner ON (mentioner.id = mentioner)
                WHERE account.handle = :1
                ORDER BY timestamp DESC
                LIMIT 1`​``

    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


(Travis Tilley) #15

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>[image:
@lattner]substantially improve error recovery for erroneous character and
stri…
<https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf>
lattner <https://github.com/lattner> authored on May 20, 2013
11471148 // String literals cannot have \n or \r in them.3bee330
<https://github.com/apple/swift/commit/3bee330e5068eb6ed4e825ff77b9e7615758eb47>[image:
@gribozavr]Lexer: don't inf loop on an unterminated string literal near EOF
<https://github.com/apple/swift/commit/3bee330e5068eb6ed4e825ff77b9e7615758eb47>
gribozavr <https://github.com/gribozavr> authored on Aug 22, 2013
1149 if (*CurPtr == '\r' || *CurPtr == '\n' || CurPtr == BufferEnd) {22610d5
<https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf>[image:
@lattner]substantially improve error recovery for erroneous character and
stri…
<https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf>
lattner <https://github.com/lattner> 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>[image:
@lattner]Initial stab at implementing string literal interpolation for
simple …
<https://github.com/apple/swift/commit/2f44c0038c5a53e6ee4bb8f0a0fec4c3bd5d79a2>
lattner <https://github.com/lattner> 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
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> {
    let db = databaseFactory().findDatabase()
    let q = `​``SELECT array_agg(mentioner.id)
                 FROM account
                 JOIN mention ON (account.id = mentioned)
                 JOIN account AS mentioner ON (mentioner.id = mentioner)
                WHERE account.handle = :1
                ORDER BY timestamp DESC
                LIMIT 1`​``

    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


(Travis Tilley) #16

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
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> {
    let db = databaseFactory().findDatabase()
    let q = `​``SELECT array_agg(mentioner.id)
                 FROM account
                 JOIN mention ON (account.id = mentioned)
                 JOIN account AS mentioner ON (mentioner.id = mentioner)
                WHERE account.handle = :1
                ORDER BY timestamp DESC
                LIMIT 1`​``

    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


(Travis Tilley) #17

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
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> {
    let db = databaseFactory().findDatabase()
    let q = `​``SELECT array_agg(mentioner.id)
                 FROM account
                 JOIN mention ON (account.id = mentioned)
                 JOIN account AS mentioner ON (mentioner.id = mentioner)
                WHERE account.handle = :1
                ORDER BY timestamp DESC
                LIMIT 1`​``

    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


(Chris Lattner) #18

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>substantially improve error recovery for erroneous character and stri… <https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf>
lattner <https://github.com/lattner> authored on May 20, 2013
1147
1148 // String literals cannot have \n or \r in them.
3bee330 <https://github.com/apple/swift/commit/3bee330e5068eb6ed4e825ff77b9e7615758eb47>Lexer: don't inf loop on an unterminated string literal near EOF <https://github.com/apple/swift/commit/3bee330e5068eb6ed4e825ff77b9e7615758eb47>
gribozavr <https://github.com/gribozavr> authored on Aug 22, 2013
1149 if (*CurPtr == '\r' || *CurPtr == '\n' || CurPtr == BufferEnd) {
22610d5 <https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf>substantially improve error recovery for erroneous character and stri… <https://github.com/apple/swift/commit/22610d5db8faa75354c42066fc586aa996a96ebf>
lattner <https://github.com/lattner> 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>Initial stab at implementing string literal interpolation for simple … <https://github.com/apple/swift/commit/2f44c0038c5a53e6ee4bb8f0a0fec4c3bd5d79a2>
lattner <https://github.com/lattner> 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?


(Jordan Rose) #19

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 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> {
    let db = databaseFactory().findDatabase()
    let q = `​``SELECT array_agg(mentioner.id <http://mentioner.id/>)
                 FROM account
                 JOIN mention ON (account.id <http://account.id/> = mentioned)
                 JOIN account AS mentioner ON (mentioner.id <http://mentioner.id/> = mentioner)
                WHERE account.handle = :1
                ORDER BY timestamp DESC
                LIMIT 1`​``

    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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Andrey Tarantsov) #20

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.