<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class="">As far as mixed whitespace, I think the only sane thing to do would be to only allow leading tabs *or* spaces. Mixing tabs and spaces in the leading whitespace would be a syntax error. All lines in the string would need to use tabs or all lines use spaces, you could not have one line with tabs and another with spaces. This would keep the compiler out of the business of making any assumptions or guesses, would not be a problem often, and would be very easy to fix if it ever happens accidentally.<br class=""></blockquote><div class=""><br class=""></div>The sane thing to do would be to require every line be prefixed with *exactly* the same sequence of characters as the closing delimiter line. Anything else (except perhaps a completely blank line, to permit whitespace trimming) would be a syntax error.<div class=""><font face="Menlo" class=""><br class=""></font>But take a moment to consider the downsides before you leap to adopt this solution.</div><div class=""><br class=""></div><div class="">1. You have introduced tab-space confusion into the equation.</div><div class=""><br class=""></div><div class="">2. You have introduced trailing-newline confusion into the equation.</div><div class=""><br class=""></div><div class="">3. The #escaped and #marginStripped keywords are now specific to multiline strings; #escaped in particular will be attractive there for tasks like regexes. You will have to invent a different syntax for it there.</div><div class=""><br class=""></div><div class="">4. This form of `"""` is not useful for not having to escape `"` in a single-line string; you now have to invent a separate mechanism for that.</div><div class=""><br class=""></div><div class=""><div class="">5. You can't necessarily look at a line and tell whether it's code or string. And—especially with the #escaped-style constructs—the delimiters don't necessarily "pop" visually; they're too small and easy to miss compared to the text they contain. In extremis, you actually have to look at the entire file from top to bottom, counting the `"""`s to figure out whether you're in a string or not. Granted, you *usually* can tell from context, but it's a far cry from what continuation quotes offer.</div></div><div class=""><br class=""></div><div class="">6. You are now forcing *any* string literal of more than one line to include two extra lines devoted wholly to the quoting syntax. In my Swift-generating example, that would change shorter snippets like this:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">code += " <br class=""> " static var messages: [HTTPStatus: String] = [<br class=""> ""<br class=""></font><br class=""></div><div class="">Into things like this:</div><div class=""><br class=""></div><div class=""><span style="font-family: Menlo;" class="">code += """</span></div><div class=""><span style="font-family: Menlo;" class=""> </span><br style="font-family: Menlo;" class=""><span style="font-family: Menlo;" class=""> static var messages: [HTTPStatus: String] = [</span></div><div class=""> <br style="font-family: Menlo;" class=""><span style="font-family: Menlo;" class=""> """</span><br style="font-family: Menlo;" class=""></div><div class=""><br class=""></div><div class="">To my mind, the second syntax is actually *heavier*, despite not requiring every line be marked, because it takes two extra lines and additional punctuation.</div><div class=""><br class=""></div><div class="">7. You are also introducing visual ambiguity into the equation—in the above example, the left margin is now ambiguous to the eye (even if it's not ambiguous to the compiler). You could recover it by permitting non-whitespace prefix characters:</div><div class=""><br class=""></div><div class=""><div class=""><div class=""><span style="font-family: Menlo;" class="">code += """</span></div><div class=""><span style="font-family: Menlo;" class=""> | </span><br style="font-family: Menlo;" class=""><span style="font-family: Menlo;" class=""> | static var messages: [HTTPStatus: String] = [</span></div><div class=""><font face="Menlo" class=""> |<br class=""></font><span style="font-family: Menlo;" class=""> |"""</span><br style="font-family: Menlo;" class=""></div></div></div><div class=""><span style="font-family: Menlo;" class=""><br class=""></span></div><div class="">...but then we're back to annotating every line, *plus* we have the leading and trailing `"""` lines. Worst of both worlds.</div><div class=""><br class=""></div><div class="">8. In longer examples, you are dividing the expression in half in a way that makes it difficult to read. For instance, consider this code:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""> socket.send( <br class=""> """ #escaped #marginStripped <br class=""> <?xml version="1.0"?><br class=""> <catalog><br class=""> <book id="bk101" empty=""><br class=""> <author>\(author)</author><br class=""> <title>XML Developer's Guide</title><br class=""> <genre>Computer</genre><br class=""> <price>44.95</price><br class=""> <publish_date>2000-10-01</publish_date><br class=""> <description>An in-depth look at creating applications with XML.</description><br class=""> </book><br class=""> </catalog><br class=""> """.data(using: NSUTF8StringEncoding))<br class=""></font></div><div class=""><br class=""></div><div class="">The effect—particularly with even larger literals than this—is not unlike pausing in the middle of reading an article to watch a movie. What were we talking about again?</div><div class=""><br class=""></div><div class="">This problem is neatly avoided by a heredoc syntax, which keeps the expression together and then collects the string below it:</div><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class=""> socket.send(""".data(using: NSUTF8StringEncoding))<br class=""> <?xml version="1.0"?><br class=""> <catalog><br class=""> <book id="bk101" empty=""><br class=""> <author>\(author)</author><br class=""> <title>XML Developer's Guide</title><br class=""> <genre>Computer</genre><br class=""> <price>44.95</price><br class=""> <publish_date>2000-10-01</publish_date><br class=""> <description>An in-depth look at creating applications with XML.</description><br class=""> </book><br class=""> </catalog><br class=""> """<br class=""></font></div></div><div class=""><br class=""></div><div class="">(I'm assuming there's no need for #escaped or #marginStripped; they're both enabled by default.)</div><div class=""><br class=""></div><div class="">* * *</div><div class=""><br class=""></div><div class="">Let's actually talk about heredocs. Leaving aside indentation (which can be applied to either feature) and the traditional token choices (which can be changed), I think these are the pros of heredocs compared to Python triple-quotes:</div><div class=""><br class=""></div><div class="">H1: Doesn't break up expressions, as discussed above.</div><div class="">H2: Literal content formatting is completely unaffected by code formatting, including the first and last lines.</div><div class=""><br class=""></div><div class=""><div class="">Here are the pros of Python triple-quotes compared to heredocs:</div></div><div class=""><br class=""></div><div class="">P1: Simpler to explain: "like a string literal, but really big".</div><div class="">P2: Lighter syntactic weight, enough to make`"""` usable as a single-line syntax.</div><div class="">P3: Less trailing-newline confusion.</div><div class=""><br class=""></div><div class="">(There is one other difference: `"""` is simpler to parse, so we might be able to get it in Swift 3, whereas heredocs probably have to wait for Swift 4. But I don't think we should pick one feature over another merely so we can get it sooner. It's one thing if you plan to eventually introduce both features, as I plan to eventually have both continuation quotes and heredocs, to introduce each of them as soon as you can; it's another to actually choose one feature over another specifically to get something you can implement sooner.)</div><div class=""><br class=""></div><div class="">But the design you're discussing trades P2 and P3—and frankly, with the mandatory newlines, part of P1—away in an attempt to get H2. So we end up deciding between these two selling points:</div><div class=""><br class=""></div><div class="">* This triple-quotes design: Simpler to explain.</div><div class="">* Heredocs: Doesn't break up expressions.</div><div class=""><br class=""></div><div class="">Simplicity is good, but I really like the code reading benefits of heredocs. Your code is your code and your text is your text. The interface between them is a bit funky, but within their separate worlds, they're both pretty nice.</div><div class=""><br class=""></div><div class="">* * *</div><div class=""><br class=""></div><div class="">Either way, heredocs or multiline-only triple quotes could be tweaked to support indentation by using the indentation of the end delimiter. But as I explained above, I don't think that's a great idea for either triple quotes *or* heredocs—the edge of the indentation is not visually well defined enough.</div><div class=""><br class=""></div><div class="">That's why I came to the conclusion that trying to cram every multiline literal into one syntax is trying to cram too many peg shapes into one hole shape. Indentation should *only* be supported by a dedicated syntax which is also designed for the smallest multiline strings, where indentation support is most useful. A separate feature without indentation support should handle longer strings, where the length alone is so disruptive to the flow of your code that there's just no point even trying to indent them to match (and the break with normal indentation itself assists you in finding the end of the string).</div><div class=""><br class=""></div><div class="">And I think that the best choice for the first feature is continuation quotes, and for the second is heredocs. Triple-quote syntaxes—either Python's or this modification—are jacks of all trades, but masters of none.</div><div class=""><br class=""></div><div class=""><div class="">-- <br class="">Brent Royal-Gordon<br class="">Architechies<br class=""></div><br class=""></div></body></html>