<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 <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> 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 <<a href="mailto:ttilley@gmail.com" class="">ttilley@gmail.com</a>> 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. Are you asking whether a proposal should start out simple, then have new things piled on top of it? 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. This avoids painting ourselves into a corner. Further, I really hope we can avoid adding N new string literal syntaxes. 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. “”” doesn’t seem problematic to me though.</div><div>- Please consider ways that the string can have extensible options applied to it. 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). </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. 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). 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. 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 </div><div class="">blah</div><div class=""> blah```</div><div class=""><br class=""></div><div class="">-Chris</div></body></html>