[swift-evolution] multi-line string literals

Fri Dec 11 17:28:25 CST 2015

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 at 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 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/20151212/0a84536c/attachment.html>