<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Why don't we just use the back ticks " ` ", making it similar to markup:</div><div><br></div><div>let code =</div><div>```</div><div>main = interact id</div><div>```</div><div><br></div><div>I believe nobody would ever want to put three back ticks inside a string.</div><div><br></div><div>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):</div><div><br></div><div>let myString = "Hello!"</div><div>let code =</div><div>```</div><div>main = p "``` + myString + ```"</div><div> where p = putStrLn</div><div>```</div><div><br></div><div>(Shorter would be to drop the "+" with some compiler magic, but that's meh)</div><div><br></div><div>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.</div><div><br></div><div><br>On 11 Dec 2015, at 18:29, Travis Tilley via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">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:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">let foo = """</div><div class="gmail_default" style="font-family:verdana,sans-serif"> hell yeah, escapes! \n\n</div><div class="gmail_default" style="font-family:verdana,sans-serif"> \(sound) like a "\(animal)"</div><div class="gmail_default" style="font-family:verdana,sans-serif"> this is another completely random line</div><div class="gmail_default" style="font-family:verdana,sans-serif">"""<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Would have a foo variable containing (note the stripped indentation, as that seems to be the popular request in this thread):</div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class="gmail_quote">hell yeah, escapes!<br><br>moo like a "cow"<br>this is another completely random line</blockquote><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">But if wrapped by ''' then none of the interpolation or escape processing happens (and quotes still don't need to be escaped).</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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)</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">- Travis Tilley</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 11, 2015 at 12:01 PM, John Siracusa via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>-John<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 11, 2015 at 11:52 AM, John Siracusa <span dir="ltr"><<a href="mailto:siracusa@gmail.com" target="_blank">siracusa@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span class=""><div><br></div><div>Chris Lattner wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.</blockquote><div><br></div></span><span class=""><div>Travis Tilley wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.</blockquote><div><br></div></span><div><div>Jokes aside, the ability to choose delimiters for strings and other language constructs that surround some value is a huge boon to code readability.</div><div><br></div><div>For example, RegExp literals in JavaScript:</div><div><br></div><div>var regex = /^\/usr\/local\//; // gross</div><div><br></div><div>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.</div><div><br></div><div>message = "\"I don't like this,\" she said."; // nope</div><div>message = '"I don\'t like this," she said.'; // still nope</div><div><br></div><div>Then, of course, there's your escape character itself:</div><div><br></div><div>escapes = "Some escapes: \\n, \\t, \\a"; // sigh</div><div><br></div><div>There are many time-tested solutions to these syntactic/cosmetic problems. </div><div><br></div><div>* Different delimiters with different interpolation rules (e.g., single quotes not honoring any backslash escapes and not doing variable interpolation)</div><div><br></div><div>* 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.)</div><div><br></div><div>* Heredocs for long literals where you get to pick the end token.</div><div><br></div><div>* Heredocs modified by delimiters around the end token to control interpolation within the long literal.</div><div><br></div><div>Which language looks like line noise now?</div><div><br></div><div><span style="white-space:pre-wrap"> </span>$messasge = q("I can't believe how nice this is," she said (quietly).);</div><div><br></div><div><span style="white-space:pre-wrap"> </span>$regex = qr(^/usr/local/);</div><div><br></div><div><span style="white-space:pre-wrap"> </span>$escapes = 'Some escapes: \n, \t, \a';</div><div><br></div><div>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. </div><span><font color="#888888"><div><br></div><div>-John</div></font></span></div><div><br></div></div>
</blockquote></div><br></div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=qZpXMk9vJDqToeTsZCIqiZt6H6WbJ-2F4cetScK5CvwczCEWW-2BI3OMLZu7GD-2BgsYQ9NDqs118P1PwLmtiYZehKrBEZSFtUW8bnydcWaNaL-2FFC60nd-2FwOFOKEDsa8QWe-2BCND3Iayy4iVeG1kfuxfMx11dg1-2BTBo1Kp15xhSRjWi77R8wd4wuyrLaKAAyNpujf9P-2FoX0PEsi2JTEGlePF6sVxm-2Bg9WF34lkwKUQ3uLLUckA-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br>
</div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=UMghxGHOvTEcVGG3PKHzuJe-2F1jwKPcDcSNH0SiRhP17Nz0QJo2F3Ck18os9XjPTy-2Bfr5qI-2B7tv-2FPGqZLlz6fLEx9iUzluJTEbWvqGiAXpk9lBT1j6EETYupvoD9-2B5DG2MuShMNtiFQqFL3wqaxDhiHiv5zbjbe0K4cfqQNYsm3N6pwxs2Wdjk-2FTk9SFa6wbLFgj0gHfa-2BbfjxjPLxQh0SVaMoL2jOuyuVoKzUyq878k-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>