[swift-evolution] multi-line string literals

[Travis Tilley]

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 at 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 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/34ab5bdd/attachment.html>