[swift-evolution] multi-line string literals

[Travis Tilley]

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 at 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 at 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 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
>>
>>
> _______________________________________________
> 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/b7fe798b/attachment.html>