<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="">What about the following proposal, I’m afraid I don’t know if it’s possible to implement, but it really represents everything that I would like to see in a multiline String solution because it has no special syntax and the results are extremely straight forward and non-magical.<div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">let</span> x =</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"This is a proposal for a multiline literal String in Swift. This syntax solves a number of problems that</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"are common in other language's implementations of multiline Strings. This syntax is meant to be a</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"a generalization of regular Swift literal Strings, whereby a String is considered to begin with an open quote</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"and continue indefinitely until and including the end of the line (newline character),</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"or the String is closed with an ending quote.</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"Firstly, indentation is now very clear and explicit. It is easy to see what the resulting string will be.</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">" This is one level of indentation.</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">" This is two levels.</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"Secondly, there is no need for newline character processesing since it is well defined what newline behavior</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"should be.</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"If a newline should be present in the code, but not in the resulting String it can be escaped with '<a href="smb://'" class="">\\'</a> \</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">" like so.</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"Alternatively, perhaps that behavior could be left out and still accomplished by appending Strings in the</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">" normal way with + or implicitly concatonated by the complier. Like so:</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">" This is a long single line literal String. This is a long single line literal String. This is a long single"</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"line literal String."</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"Thirdly, the indent level of these strings is decoupled from the indent level of the code, since there is a</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class=""> "well defined starting point for the String on each line.</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class=""> " Thus you can indent the code and the string independently.</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"Lastly, I don't actually know if this is even possible to implement. I don't know if these creates ambiguities</font></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><font color="#ff2600" class="">"for the compiler, but it doesn't seem like it does at first glance.</font></div></div><div class=""><br class=""></div><div class="">This would require that adjacent Strings are automatically appended to each other by the compiler, (e.g. let x = “blah” “blah”, would be valid and x would equal “blahblah”. I don’t know how others would feel about something like this, but I’ve always wanted this behavior in multiline Strings. Perhaps I’ve forgotten some edge cases?</div><div class=""><br class=""></div><div class="">Tyler</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 14, 2015, at 12:47 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 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 class="">Catching up with the rest of this thread, here’s what I’d suggest:</div><div class=""><br class=""></div><div class="">- Please don’t extend simple “foo” strings to multiple lines.</div><div class="">- The ``` syntax is actually pretty interesting, I think that exploring it makes sense. “”” doesn’t seem problematic to me though.</div><div class="">- 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>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=DOmV4Qxg-2B1XOnX4CfTyH3sCllXs7myBcgXMCpdkqNW1JHx2f0iE7ehLq4mfarkAhhHfXCBYOXooerKaqIRIkyzZ0FDsDLwf52RSA6O3yw3HKIgPn-2B7661zRJrR-2BkRUpG-2F-2FjIKplcm-2BgSZ4FtDiLYj3272DsEznMuCn-2FK27P8XV2A7QspbWw1i3GyBHX9S7O9RYbA46Df3vFo-2FslEy4-2BeyaCK2YV-2Bu3e-2FUVoXAMTVPMA-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;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>