[swift-evolution] multi-line string literals

[Travis Tilley]

My updated thoughts, after some feedback about JSON and escaping, would be
to wrap an escaped multi-line literal with triple quotes, and to wrap an
unescaped multi-line literal with single quotes... Then, to make the
overall syntax consistent, to do the same for single-line strings. In
either case, quotes of any kind other than a triple quote would not need to
be escaped in a multi-line string literal. So:


let foo = """
  hell yeah, escapes! \n\n
  \(sound) like a "\(animal)"
  this is another completely random line
"""

Would have a foo variable containing (note the stripped indentation, as
that seems to be the popular request in this thread):

> hell yeah, escapes!
>
> moo like a "cow"
> this is another completely random line


But if wrapped by ''' then none of the interpolation or escape processing
happens (and quotes still don't need to be escaped).

Come to think of it, I don't see why a ''' syntax would -have- to be
multi-line. No reason why '''/"moo"/"cow"/g''' should be invalid from a
technical perspective. (note that swift has no native regex literal, though
you can create your own and this triple single-quote syntax might make that
less painful)


- Travis Tilley


On Fri, Dec 11, 2015 at 12:01 PM, John Siracusa via swift-evolution <
swift-evolution at swift.org> wrote:

> Sorry about the lack of a subject on this message originally. I was
> replying to the email digest and forgot to add one. It should be part of
> the "multi-line string literals" thread.
>
> -John
>
> On Fri, Dec 11, 2015 at 11:52 AM, John Siracusa <siracusa at gmail.com>
> wrote:
>
>>
>> Chris Lattner wrote:
>>
>>> When introducing a feature like this, I think it would be useful to
>>> survey a range of popular languages (and yes, even perl ;-) to understand
>>> what facilities they provide and why (i.e. what problems they are solving)
>>> and synthesize a good swift design that can solve the same problems with a
>>> hopefully simple approach.
>>
>>
>> Travis Tilley wrote:
>>
>>> ​Perl and Erlang are unique in that valid code in either language looks
>>> essentially like line noise. I'd rather take inspiration from languages
>>> like ruby, python, and elixir.​
>>
>>
>> Jokes aside, the ability to choose delimiters for strings and other
>> language constructs that surround some value is a huge boon to code
>> readability.
>>
>> For example, RegExp literals in JavaScript:
>>
>> var regex = /^\/usr\/local\//; // gross
>>
>> An even simpler example, which applies to many languages: a string
>> literal that contains all of your possible string delimiters within it.
>> This is not an exotic thing in English.
>>
>> message = "\"I don't like this,\" she said."; // nope
>> message = '"I don\'t like this," she said.';  // still nope
>>
>> Then, of course, there's your escape character itself:
>>
>> escapes = "Some escapes: \\n, \\t, \\a"; // sigh
>>
>> There are many time-tested solutions to these syntactic/cosmetic
>> problems.
>>
>> * Different delimiters with different interpolation rules (e.g., single
>> quotes not honoring any backslash escapes and not doing variable
>> interpolation)
>>
>> * Matched-pair delimiters that don't require anything to be escaped as
>> long as the delimiters are absent or matched within the string. (These
>> alone solve a huge range of problems.)
>>
>> * Heredocs for long literals where you get to pick the end token.
>>
>> * Heredocs modified by delimiters around the end token to control
>> interpolation within the long literal.
>>
>> Which language looks like line noise now?
>>
>> $messasge = q("I can't believe how nice this is," she said (quietly).);
>>
>> $regex = qr(^/usr/local/);
>>
>> $escapes = 'Some escapes: \n, \t, \a';
>>
>> My take: once you use a language where you pretty much never have to
>> backslash-escape a character you can easily type to get it into a string,
>> it's really hard to go back.
>>
>> -John
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151211/b7bf011b/attachment.html>