<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=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><span class=""></span></div><div class=""><div class=""><span class=""></span></div><div class=""><div class=""><br class=""></div><div class="">On Apr 9, 2017, at 12:29 PM, John Holdsworth via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div class="">Hi, John here, the submitter of the proposal.</div><div class=""><br class=""></div><div class="">First up, I must apologise for putting Brent on the spot when I resubmitted this altered proposal from last year. That was my mistake.</div><div class=""><br class=""></div><div class="">Second up, apologies if the proposal is rather vague on details. In some sense this was intentional as I didn’t want to get too bogged down in specifics (and not at all to do with my limitations as a technical writer!)</div><div class=""><br class=""></div><div class="">I guess we need to build up consensus more slowly by asking the following questions separately so it can be resubmitted rather than giving a binary +/-1 on the proposal as it stands.</div><div class=""><br class=""></div><div class="">1) Does Swift need multi-line string literals?</div></div></blockquote><div class=""><br class=""></div>Hi John, I think it is a "nice to have" feature. This feature would enhance multi-line string literals by removing some of the hassles such as specifying \n in each line, escaping quote characters and the concatenation character for each line of text. But best of all, the string literal would look much better in our code.<div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="">2 ) Is “””long strings””” the way to go subject to a discussion about the precise delimiter</div></div></blockquote><div class=""><br class=""></div>IMHO, I think the use of triple quote has the best feel and look.</div><div class=""><br class=""></div><div class="">I am one of the ones who had proposed several options that included a continuation character. I still like the aesthetics of having a continuation character, in particular, the quote character. For example:</div><div class=""><br class=""></div><div class=""><div class=""><font face="Monaco" class="" size="1">let xml = <font color="#ff1608" class="">"""</font><font color="#1710ff" class=""><?xml version="1.0"?></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class="">"</font><font color="#1710ff" class=""><catalog></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class="">"</font><font color="#1710ff" class=""> <book id="bk101" empty=""></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class="">"</font><font color="#1710ff" class=""> <author></font><font color="#ff1608" class="">\(</font><font color="#079b16" class="">author</font><font color="#ff1608" class="">)</font><font color="#1710ff" class=""></author></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class="">"</font><font color="#1710ff" class=""> <title>XML Developer's Guide</title></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class="">"</font><font color="#1710ff" class=""> <genre>Computer</genre></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class="">"</font><font color="#1710ff" class=""> <price>44.95</price></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class="">"</font><font color="#1710ff" class=""> <publish_date>2000-10-01</publish_date></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class="">"</font><font color="#1710ff" class=""> <description>An in-depth look at creating applications with XML.</description></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class="">"</font><font color="#1710ff" class=""> </book></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class="">"</font><font color="#1710ff" class=""></catalog></font></font></div></div><div class=""><br class=""></div><div class="">I had proposed that the multi-line string literal would end automatically when a line was found without the continuation character. This way when you start typing it, the editor would include one line at most. But I don't know if such an algorithm would be challenging for syntax highlighters. </div><div class=""><br class=""></div><div class="">I liked this option because it provided a visual guide of where each line started and found the indent of each line more predictable. But most importantly to me, this made the string literal look beautiful within my code.</div><div class=""><br class=""></div><div class="">One criticism of having a continuation character is the effort required adding the continuation character to each line. But that was okay with me because 90% of the time I typed in my string literal from scratch and indented it properly to fit with my other code. </div><div class=""><br class=""></div><div class="">I rarely ever copied / pasted a multi-line string literal directly into my code. Therefore, my goal was never to save typing, but rather to make my multi-line string literal look beautiful when surrounded by code. </div><div class=""><br class=""></div><div class="">I had also proposed to make the continuation character optional and turn off the automatic indentation stripping.</div><div class=""><br class=""></div><div class="">It is important not having to escape quotes in the the string literal. Mostly because the escaping can make the literal look ugly and a bit harder to read. </div><div class=""><br class=""></div><div class="">I also considered string interpolation a feature that would be nice to have. We already have it in normal string literals and I think It would be a mistake to not include it here. </div><div class=""><br class=""></div><div class="">The only downside to not having a closing <font color="#ff0000" class="">"""</font> is that the last line always included a newline. However, we could allow a backslash at the line to escape the newline character. As an alternative, the closing <span style="color: rgb(255, 0, 0);" class="">""" </span>could be optionally specified in the last line when continuation characters are used. However, if no continuation character was used then the closing <span style="color: rgb(255, 0, 0);" class="">""" </span>would be mandatory.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="">3) Is the “magic" leading whitespace removal a good idea to support indentation.</div></div></blockquote><div class=""><br class=""></div><div class="">I think that is reasonable. I do consider leading white space removal a highly desirable feature. </div><br class=""><blockquote type="cite" class=""><div class=""><div class="">4) Does the proposal contain sufficient detail to be discussed/implemented</div></div></blockquote><div class=""><br class=""></div>I think the proposal should include more examples and some edge cases that illustrate how this feature will work. </div><div class=""><br class=""></div><div class="">For example, if the last line does not have a newline character then I would end my string like this:</div><div class=""><br class=""></div><div class=""><div class=""><font face="Monaco" class="" size="1">let xml = <font color="#ff1608" class="">"""</font><font color="#1710ff" class=""><?xml version="1.0"?></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class=""> </font><font color="#1710ff" class=""><catalog></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class=""> </font><font color="#1710ff" class=""> <book id="bk101" empty=""></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class=""> </font><font color="#1710ff" class=""> <author></font><font color="#ff1608" class="">\(</font><font color="#079b16" class="">author</font><font color="#ff1608" class="">)</font><font color="#1710ff" class=""></author></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class=""> </font><font color="#1710ff" class=""> <title>XML Developer's Guide</title></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class=""> </font><font color="#1710ff" class=""> <genre>Computer</genre></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class=""> </font><font color="#1710ff" class=""> <price>44.95</price></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class=""> </font><font color="#1710ff" class=""> <publish_date>2000-10-01</publish_date></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class=""> </font><font color="#1710ff" class=""> <description>An in-depth look at creating applications with XML.</description></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class=""> </font><font color="#1710ff" class=""> </book></font></font></div><div class=""><font face="Monaco" class="" size="1"> <font color="#ff1608" class=""> </font><font color="#1710ff" class=""></catalog></font></font><span style="color: rgb(255, 22, 8); font-family: Monaco; font-size: x-small;" class="">"""</span></div><div class=""><span style="color: rgb(255, 22, 8); font-family: Monaco; font-size: x-small;" class=""><br class=""></span></div><div class="">What would be the amount of indentation stripped here? I would expect the white space preceding the last line containing the </catalog> would be the amount of indentation stripped from each line.</div><div class=""><br class=""></div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">My answer to 1) is obviously yes and I think the discussion has come out about 50/50 so far so lets persevere...</div><div class=""><br class=""></div><div class="">Trying to fie down 2), a “””long string””” or @“long string”@ or _”long string”_ or #”long string”# is a string literal inside a new delimiter. It would be processed exactly as it would a normal string including escapes and interpolation except the string can include unescaped “ or “" and newlines. Also, a \ at the end of the line would mean that particular newline is not included in the string.</div><div class=""><br class=""></div><div class="">For me, the goals of a long string are that it should be able to pasted in (almost) without modification from a text source and that syntax highlighting would work for the widest possible range of text editors and github. “””long string””” is just a trick Python uses to satisfy the second goal (for example <a href="https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf#file-multiline-swift-L97" class="">this gist</a>) but highlighting also works for asymmetric delimiters such as @“long string”@ which avoid potential problems with “inversion”. Heredoc or a Swifty #equivalent does not satisfy this second goal at all well and IMHO it should be excluded. It would also be significantly more difficult to integrate into the Swift compiler.</div><div class=""><br class=""></div><div class="">Looking at 3) which is underspecified in the proposal perhaps, I’d consider it a “feature" but I can see it would be too magical for some. To specify it more you could say: if there is only whitespace between the last newline and the end of a multiline literal this whitespace will be stripped from all lines in the literal. If lines do not start with this exact sequence of whitespace a warning is emitted. In addition, if the first character in the literal is a newline it will be removed. This operation could be made explicit e.g. <font face="Menlo" class=""><span style="font-size: 11px;" class="">#trimLeft(“”"a literal""")</span></font></div><div class=""><br class=""></div><div class="">Perhaps we can find common ground on 1) and 2) and even 3) with a view to resubmitting if there is time. Seems mostly like we just need to discuss the delimiter further and decide whether the indent trimming is a bug or a feature to keep moving and not let another year slip by.</div><div class=""><br class=""></div><div class="">With respect to 4) I’m updating <a href="https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md" class="">https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md</a> as the proposal is discussed to fill in some of the gaps & I’ve prepared a toolchain for Swift 3 if you want to <a href="http://johnholdsworth.com/swift-LOCAL-2017-04-09-a-osx.tar.gz" class="">try an implementation out </a></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On 9 Apr 2017, at 15:35, Thorsten Seitz 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=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md</a></blockquote></div></div></blockquote><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">What is your evaluation of the proposal?</div></div></div></blockquote><div class=""><br class=""></div>+1</div><div class=""><br class=""></div><div class="">My foremost expectation from multiline string literals is to be able to copy and paste multiline string literals without having to fiddle with escape marks or leading and trailing quotes or continuation characters. This is exactly what the proposal provides and makes it easy to embed SQL, for example (using SQL parameters and not string interpolation of course ;-)</div><div class=""><br class=""></div><div class="">The chosen deindentation rules seem very pragmatic and useful to me.</div><div class=""><br class=""></div><div class="">Additional features for multiline string literals can be added easily later.</div><div class=""><br class=""></div><div class="">I would expect multiline string literals to use the same newline character as "\n“ does, regardless of the newline character actually used in the file.</div><div class="">Furthermore all normal escapes, e.g. \n, \t etc. should probably be available as well. </div><div class="">This should be stated explicitly in the proposal.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Yes.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Does this proposal fit well with the feel and direction of Swift?<br class=""></div></div></div></div></blockquote><div class=""><br class=""></div>Yes.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""></div></div></div></div></blockquote><div class=""><br class=""></div>For setting the ground it compares favourably.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""></div></div></div></div></blockquote><br class=""></div><div class="">Followed most discussions, read the proposal.</div><div class=""><br class=""></div><div class="">-Thorsten</div><br 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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></div></div></body></html>