[swift-evolution] multi-line string literals

[Drew Crawford]

That's an interesting idea!  What about """ for escaped strings and ``` for unescaped literal strings?

The latter is intuitive for me for preformatted text (with JSON et al are), and Swift in fact uses Markdown for doc comments, so we assume some familiarity from the developer.


> On Dec 11, 2015, at 5:21 PM, Travis Tilley via swift-evolution <swift-evolution at swift.org> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/825de3f0/attachment.html>