<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 14, 2015, at 12:35 PM, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 10, 2015, at 11:07 PM, Travis Tilley &lt;<a href="mailto:ttilley@gmail.com" class="">ttilley@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:verdana,sans-serif">Chris - due to the complexity involved, would it make sense to have multiple proposals? One syntax need not fulfill the needs of every use case. </div></div></div></blockquote><div class=""><br class=""></div><div class="">I’m not sure how to interpret this question. &nbsp;Are you asking whether a proposal should start out simple, then have new things piled on top of it? &nbsp;Or are you suggesting it would be better to have multiple new language features solving different problems?</div><div class=""><br class=""></div><div class="">In this case, my personal preference is to have a really well thought out long term vision for what we are doing in this space, and then subset the implementation to start with the simple pieces. &nbsp;This avoids painting ourselves into a corner. &nbsp;Further, I really hope we can avoid adding N new string literal syntaxes. &nbsp;I see the existing one as the “simple” case, and the multiline case as the “advanced” case which can have knobs put on it for other advanced uses.</div></div></div></div></blockquote><br class=""></div><div>Catching up with the rest of this thread, here’s what I’d suggest:</div><div><br class=""></div><div>- Please don’t extend simple “foo” strings to multiple lines.</div><div>- The ``` syntax is actually pretty interesting, I think that exploring it makes sense. &nbsp;“”” doesn’t seem problematic to me though.</div><div>- Please consider ways that the string can have extensible options applied to it. &nbsp;I haven’t thought much about this space, but the "<font face="Helvetica Neue" class="">String literal suffixes for defining types” has some interesting ideas (though using prefixes instead of suffixes seems appealing as was pointed out in some email).&nbsp;</font></div>- I completely agree with Brent’s observation that we shouldn’t optimize for multi-line literals embedded into the middle of some other large expression.<br class=""><div class=""><br class=""></div><div class="">The “configuration” aspect of this feature has come up several times. &nbsp;It seems clear that the multi line literal has some obvious strong defaults: leading whitespace should be stripped, and escapes should be processed (including interpolation). &nbsp;That said, being able to disable these independent of each other is important, and there are lots of other behaviors that can be considered as well. &nbsp;I consider it a good thing for these behaviors to be explicit in the code.</div><div class=""><br class=""></div><div class="">As a strawman proposal (i.e. don’t take it seriously) to illustrate what I mean, you could use attributes for this, e.g. something like:</div><div class=""><br class=""></div><div class="">let foo = @disable_escape_processing ```</div><div class="">blah&nbsp;</div><div class="">blah</div><div class="">&nbsp;blah```</div><div class=""><br class=""></div><div class="">-Chris</div></body></html>