<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 May 11, 2016, at 12:55 PM, Vladimir.S <<a href="mailto:svabox@gmail.com" class="">svabox@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">On 11.05.2016 19:38, Ricardo Parada wrote:<br class=""><blockquote type="cite" class="">I did not suggest the single quote because it is commonly found in the<br class="">English language and we would have to escape it.<br class=""></blockquote><br class="">Wel.. in your document you have a number of variants of multi-line 'feature' implementations with different pros/cons for each.<br class=""></div></div></blockquote><br class="">I don’t have a document. I’ve seen different proposals. </div><div>I have just been commenting on the proposals in this thread.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Could you clarify, why this proposal with single quote can not be inside your document as just another variant with its own pros/cons ? Especially, as you can see, if "We'd rather save single quoted literals for a greater purpose (e.g. non-escaped string literals)” ?<br class=""></div></div></blockquote><div><br class=""></div>I cannot speak for them, but I think that if we want to get a feel about which alternatives get the most traction, I think all alternatives should be considered, including yours and mine. :-)<br class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><br class="">That is why I suggested a rare combination using the @" and "@ as the<br class="">delimiters. Unless your text is Obj-C code it would be rare to find it.<br class=""><br class=""></blockquote></div></div></blockquote><div><br class=""></div><div>I don’t think we need to worry about the opening quote occurring in the text because we just need the closing delimiter to find out where it ends. For example:</div><div><br class=""></div><div><br class=""></div><div><span class="pl-k" style="white-space: pre; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; vertical-align: top; box-sizing: border-box; color: rgb(167, 29, 93);">let</span><font face="Consolas, Liberation Mono, Menlo, Courier, monospace" class="" style="color: rgb(51, 51, 51); font-size: 13px; white-space: pre;"><span class="" style="font-size: 12px; vertical-align: top;"> sourceCode </span></font><span class="pl-k" style="white-space: pre; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; vertical-align: top; box-sizing: border-box; color: rgb(167, 29, 93);">=</span><font face="Consolas, Liberation Mono, Menlo, Courier, monospace" class="" style="color: rgb(51, 51, 51); font-size: 13px; white-space: pre;"><span class="" style="font-size: 12px; vertical-align: top;"> </span></font><font face="Menlo" class="" style="white-space: pre;"><span class="" style="color: rgb(0, 86, 214); font-size: 11px;">@“</span><span class="" style="font-size: 11px;"><font color="#d12f1b" class="">NSString *firstName = @“John”;</font></span></font><div class="" style="font-family: Menlo; font-size: 11px; vertical-align: top; margin: 0px; line-height: normal; color: rgb(209, 47, 27);"><span class="" style="font-variant-ligatures: no-common-ligatures;"> <span class="" style="color: rgb(0, 86, 214); white-space: pre;">"</span></span><span style="white-space: pre;" class="">NSString *lastName = @“Doe”;</span></div><div class="" style="vertical-align: top; margin: 0px; line-height: normal;"><font color="#0056d6" face="Menlo" class=""><span class="" style="font-size: 11px; white-space: pre;"><span style="color: rgb(209, 47, 27);" class=""> </span>“</span></font><font color="#d12f1b" face="Menlo" class=""><span style="font-size: 11px; white-space: pre;" class="">NSString *fullName = [NSString stringWithFormat: @“%@ %@“, firstName, lastName];</span></font><span class="" style="font-family: Menlo; font-size: 11px; color: rgb(51, 51, 51); font-variant-ligatures: no-common-ligatures;"><font color="#0056d6" class="">"</font></span><span class="" style="color: rgb(51, 51, 51); font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; white-space: pre;"><font color="#0056d6" class="">@</font></span></div><div class=""><br class=""></div><div class="">The one that would be a bit of a problem is the closing delimiter,</div><div class=""><span class="" style="font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; white-space: pre;"><font color="#0056d6" class=""><br class=""></font></span></div></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">And what do you suggest to do if we *have* `"@` inside the text we want to use ?<br class=""><br class=""><blockquote type="cite" class=""><br class=""><br class=""><blockquote type="cite" class="">On May 11, 2016, at 10:50 AM, Vladimir.S via swift-evolution<br class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Did I miss the proposal for single quote?<br class=""><br class="">Just found on<br class=""><a href="https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md" class="">https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md</a><br class=""><blockquote type="cite" class=""><br class=""></blockquote><br class=""></blockquote></blockquote>---------------------<<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Single-quotes '' for Character literals: Swift takes the approach of<br class="">highly valuing Unicode. However, there are multiple concepts of a<br class="">character that could make sense in Unicode, and none is so much more<br class="">commonly used than the others that it makes sense to privilege them.<br class="">We'd rather save single quoted literals for a greater purpose (e.g.<br class="">non-escaped string literals).<br class=""><blockquote type="cite" class="">---------------------<<br class=""></blockquote><br class="">So, what about using of single quote as "special" strings?<br class=""><br class="">For example, I'd propose to use single quote quotation to say "this<br class="">string should be used as-is, no escapes processing"<br class=""><br class="">'some 1\total\\2\\\3 "sdfsdf" \(-: """ helllooo'<br class=""><br class="">the only 'disallowed' symbol could be the single quote itself, but I<br class="">propose the solution used in other languages - duplicate it if we need<br class="">it in string:<br class=""><br class="">'this '' is a single quote in string, and this is another'''<br class=""><br class="">and also in multiline strings:<br class=""><br class="">assert( xml == '<?xml version="1.0"?> '<catalog> ' <book id="bk101"<br class="">empty=""> ' <author>\(author)</author> // note '' here in<br class="">string ' <title>XML Developer''s Guide</title> '<br class=""><genre>Computer</genre> ' <price>44.95</price> '<br class=""><publish_date>2000-10-01</publish_date> ' <description>An<br class="">in-depth look at XML.</description> ' </book> '</catalog>')<br class=""><br class="">(also needs to duplicate single quote if in text. the compromise,<br class="">yes.)<br class=""><br class=""><blockquote type="cite" class="">On 10.05.2016 9:53, John Holdsworth via swift-evolution wrote: I’ve<br class="">assembled a gist to summarise the main proposals of this thread.<br class=""><br class=""><a href="https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf" class="">https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf</a><br class=""><br class="">At the moment there seem to be four proposals for multi-line<br class="">strings:<br class=""><br class="">1) Bent’s proposal for continuation quotes where if a conventional<br class="">string does not close, if the first non-whitespace character of the<br class="">next line is “ (or perhaps |) the string is continued. This gives<br class="">you precise control over exactly what is in the string.<br class=""><br class="">2) Tyler's original proposal involving strings that can contain<br class="">newlines delimited “””like this“”” as they are in python or, _”like<br class="">this“_. This works well in external editors and on github.<br class="">Indentation is catered for by stripping any whitespace before the<br class="">closing quote from all lines in the string.<br class=""><br class="">3) HEREDOC syntax <<“TAG” or <<‘TAG’ taken from languages like Perl<br class="">subject to the same indentation removal rules as “””strings”””<br class="">above. This has the advantage that the literal is clearly separated<br class="">from your code.<br class=""><br class="">4) Heck it all, why not all three syntaxes or some combination.<br class=""><br class="">(There is a separate feature that all string literals can be<br class="">prefixed by e as in e”\w\d+” to turn of all escape processing for<br class="">another day)<br class=""><br class="">While the Swift Lexer could easily accommodate all these syntaxes<br class="">there was talk early on that Swift has more of a "one way, maximally<br class="">elegant” ethos and indeed I find it difficult imagine the Swift Book<br class="">breathlessly describing all three formats so I’m wondering if push<br class="">came to shove which format people would chose?<br class=""><br class="">My vote having undergone a "road to damascus" moment now we know it<br class="">is available sooner rather than later is.. HEREDOC! It’s well<br class="">understood and while at first it would seem to not be a good fit for<br class="">Swift produces clear code.<br class=""><br class="">Votes?<br class=""><br class="">John<br class=""><br class=""><br class="">// Multi-line string proposals //<br class="">https://github.com/apple/swift/pull/2275<br class=""><br class="">// swift-evolution thread: //<br class="">http://thread.gmane.org/gmane.comp.lang.swift.evolution/904/focus=15133<br class=""><br class=""><br class=""><br class=""></blockquote></blockquote></blockquote>// These examples should load in the prototype toolchain available<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">here: //<br class=""><a href="http://johnholdsworth.com/swift-LOCAL-2016-05-09-a-osx.tar.gz" class="">http://johnholdsworth.com/swift-LOCAL-2016-05-09-a-osx.tar.gz</a><br class=""><br class="">// The prototype currently parses three new forms of quoting //<br class="">These new types are still string literals for the grammar.<br class=""><br class="">"the existing string literal format" _"a format that does not<br class="">require you to escape " characters"_ // possibly redundant """a<br class="">python-style syntax that will accept "'s and newlines in the<br class="">string""" <<"HEREDOC" A full heredoc implementation (will always end<br class="">in a newline) HEREDOC<br class=""><br class="">// These strings can be modified by prefixing the string by letters<br class="">// There is currently only one, "e" to disable escape processing. //<br class="">This is primarily used when specifying regular expressions.<br class=""><br class="">letstr = "print(\"Hello, world!\\n\")"<br class=""><br class="">assert( e"print(\"Hello, world!\n\")"== str ) assert(<br class="">e_"print("Hello, world!\n")"_ == str ) assert( e"""print("Hello,<br class="">world!\n")""" == str )<br class=""><br class="">// Continuation quotes allow you to extend a standard string<br class="">literal // over multiple lines. If a string does not close on a line<br class="">and the // first non-whitespace character on the next line is " that<br class="">line // will be a contination of the string including the newline<br class="">character // (unless it is escaped). Interpolation and escapes<br class="">process as before // unless the first segment of the string is<br class="">modified by the "e" prefix.<br class=""><br class="">// The advantage of this format allows you to indent while giving //<br class="">you precise control of exactly what is going into the literal.<br class=""><br class="">letauthor = "Gambardella, Matthew"<br class=""><br class="">letxml = "<?xml version=\"1.0\"?> "<catalog> " <book id=\"bk101\"<br class="">empty=\"\"> " <author>\(author)</author> " <title>XML<br class="">Developer's Guide</title> " <genre>Computer</genre> "<br class=""><price>44.95</price> "<br class=""><publish_date>2000-10-01</publish_date> " <description>An<br class="">in-depth look at creating applications with XML.</description> "<br class=""></book> "</catalog> "" print(xml)<br class=""><br class="">// Perhaps, to avoid the zera crossing effect in text editors due<br class="">to // the unbalanced quotes, the continuation character could be<br class="">"|". // (newlines escaped with \ and blank lines are discarded.)<br class=""><br class="">assert( xml == "\ |<?xml version=\"1.0\"?> |<catalog> | <book<br class="">id=\"bk101\" empty=\"\"> | <author>\(author)</author> |<br class=""><title>XML Developer's Guide</title> |<br class=""><genre>Computer</genre> | <price>44.95</price> |<br class=""><publish_date>2000-10-01</publish_date> | <description>An<br class="">in-depth look at creating \ |applications with XML.</description><br class=""><br class="">| </book> |</catalog> |")<br class=""><br class=""><br class="">// _""_ quoted strings also suppport these behaviours but don't<br class="">require // escaping of embedded " characters. Think of them as a<br class="">being modifier // on conventional string literals. They support<br class="">continuation quotes.<br class=""><br class="">assert( xml == _"<?xml version="1.0"?> "<catalog> " <book<br class="">id="bk101" empty=""> " <author>\(author)</author> "<br class=""><title>XML Developer's Guide</title> "<br class=""><genre>Computer</genre> " <price>44.95</price> "<br class=""><publish_date>2000-10-01</publish_date> " <description>An<br class="">in-depth look at creating applications with XML.</description> "<br class=""></book> "</catalog>\n"_ )<br class=""><br class="">// _"strings"_ could allow newlines and replace """strings"""<br class="">discussed next<br class=""><br class="">assert( xml == _"<?xml version="1.0"?> <catalog> <book id="bk101"<br class="">empty=""> <author>\(author)</author> <title>XML Developer's<br class="">Guide</title> <genre>Computer</genre> <price>44.95</price><br class=""><publish_date>2000-10-01</publish_date> <description>An in-depth<br class="">look at creating applications with XML.</description> </book><br class=""></catalog> "_ )<br class=""><br class="">// The triple quoted strings can contain newlines and, unless<br class="">modified by "e" // will process interpolations and not require<br class="">escaping of ". To allow indenting, // any whitespace characters that<br class="">preceed the closing """ will be removed from // each line of the<br class="">final literal. A warning is shown if lines do not contain // the<br class="">exact same indentation characters. Any intial linefeed is also<br class="">removed.<br class=""><br class="">// The advantage of this format is the """ introducer works well<br class="">when syntax // highlighting in external editors and github as quotes<br class="">are always balanced.<br class=""><br class="">assert( xml == """ <?xml version="1.0"?> <catalog> <book id="bk101"<br class="">empty=""> <author>\(author)</author> <title>XML Developer's<br class="">Guide</title> <genre>Computer</genre> <price>44.95</price><br class=""><publish_date>2000-10-01</publish_date> <description>An in-depth<br class="">look at creating applications with XML.</description> </book><br class=""></catalog> """ )<br class=""><br class="">assert( xml != e"""<?xml version="1.0"?> <catalog> <book id="bk101"<br class="">empty=""> <author>\(author)</author> <title>XML Developer's<br class="">Guide</title> <genre>Computer</genre> <price>44.95</price><br class=""><publish_date>2000-10-01</publish_date> <description>An in-depth<br class="">look at creating applications with XML.</description> </book><br class=""></catalog> """ )<br class=""><br class="">// heredoc syntax comes in two variants <<"TAG" and <<'TAG'<br class="">(non-escaping, "e" prefix) // It applies the same indentation<br class="">removal rules as does """. This change has wider // ramifications<br class="">for the toolchain as compiler tokens are no longer in file order //<br class="">and will take a while for a few problems to be ironed out. The more<br class="">consistent // <<e"TAG" is a rather clumsy alternative to <<'TAG'<br class="">for non-escaping strings.<br class=""><br class="">// HEREDOC's advantage is that the literal no longer interrupts the<br class="">flow of your code.<br class=""><br class="">assert( (<<"XML" + <<"XML") == xml + xml ) <?xml version="1.0"?><br class=""><catalog> <book id="bk101" empty=""> <author>\(author)</author><br class=""><title>XML Developer's Guide</title> <genre>Computer</genre><br class=""><price>44.95</price> <publish_date>2000-10-01</publish_date><br class=""><description>An in-depth look at creating applications with<br class="">XML.</description> </book> </catalog> XML <?xml version="1.0"?><br class=""><catalog> <book id="bk101" empty=""> <author>\(author)</author><br class=""><title>XML Developer's Guide</title> <genre>Computer</genre><br class=""><price>44.95</price> <publish_date>2000-10-01</publish_date><br class=""><description>An in-depth look at creating applications with<br class="">XML.</description> </book> </catalog> XML<br class=""><br class="">// For text you do not want to contain newlines, escape them using<br class="">\<br class=""><br class="">print( <<"LOREM" ) Lorem ipsum dolor sit amet, consectetur<br class="">adipiscing elit, sed do eiusmod tempor incididunt \ ut labore et<br class="">dolore magna aliqua. Ut enim ad minim veniam, quis nostrud<br class="">exercitation ullamco \ laboris nisi ut aliquip ex ea commodo<br class="">consequat. Duis aute irure dolor in reprehenderit in \ voluptate<br class="">velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint<br class="">occaecat cupidatat \ non proident, sunt in culpa qui officia<br class="">deserunt mollit anim id est laborum.\ LOREM<br class=""><br class=""><br class=""><br class=""><br class=""><br class="">_______________________________________________ swift-evolution<br class="">mailing list swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></blockquote>_______________________________________________ swift-evolution<br class="">mailing list <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=""></blockquote><br class=""></blockquote></div></div></blockquote></div><br class=""></body></html>