[swift-evolution] multi-line string literals

[Travis Tilley]

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 at 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 at 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 at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151212/2c8241e1/attachment.html>