<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 10, 2015, at 1:56 PM, Travis Tilley via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:verdana,sans-serif">I would very much like to implement multi-line string literals in swift and get feedback on what this should look like, as i've been informed there are several competing suggestions filed as radars.</div></div></div></blockquote><div><br class=""></div><div>I’m positive about adding some syntax for multi-line string literals. &nbsp;Some questions to think about and debate on this list:</div><div><br class=""></div><div>1) What concrete syntax should be used? &nbsp;There are a lot of options in this space across a wide range of languages. &nbsp;C++ has raw strings, and this page has more examples:</div><div><a href="http://rigaux.org/language-study/syntax-across-languages.html#StrngMltLine" class="">http://rigaux.org/language-study/syntax-across-languages.html#StrngMltLine</a></div><div><br class=""></div><div>2) Should escapes like \n be processed always, should they never be processed, or should they be processed by default but disable-able in the syntax?</div><div><br class=""></div><div>3) What other policy decisions make sense to expose on these literals? &nbsp;Since this will be the “powerful form of string literals”, it makes sense to be the place to put weird knobs that are seldom used but important in various cases.</div><div><br class=""></div><div>I assume that this would tie into the existing literal convertible protocols, and if/when escaping is supported that it would support interpolation as well.</div><div><br class=""></div><div>-Chris</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""></div><div class="gmail_default" style="font-family:verdana,sans-serif">My initial improvement request is here:&nbsp;<a href="https://bugs.swift.org/browse/SR-170" class="">https://bugs.swift.org/browse/SR-170</a></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""></div><div class="gmail_default"><font face="verdana, sans-serif" class="">It is only an opinion, but it's my belief that simple python-style multi-line string literals are the way to go. They're simple and, in the end, exactly the same as normal string literals. They begin and end with triple quotes, can contain newlines, can contain single quotes, and that's all that's special in their parsing. The same block of code in&nbsp;Lexer.cpp could be used for both types of literal, ensuring behavior is always consistent regardless of any future changes.</font></div><div class="gmail_default"><font face="verdana, sans-serif" class=""><br class=""></font></div><div class="gmail_default" style="font-family:verdana,sans-serif">There is also the potential suggestion of removing consistent indentation if there is any so as to make formatting of a multi-line string literal look more clean when indented. For me, it would be a nice to have, but not a make or break feature... and for some it may be confusing.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""></div><div class="gmail_default" style="font-family:verdana,sans-serif">I'd like to state that I'm not proposing heredoc-style functionality, as I believe that to be an entirely separate feature. The potential to have one heredoc embedded within another would certainly make parsing more painful than i'm happy with.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""></div><div class="gmail_default" style="font-family:verdana,sans-serif">For an example of code that would benefit significantly from multi-line string literals, please look at docopt.swift:&nbsp;<a href="https://github.com/docopt/docopt.swift/blob/master/Examples/Swift/arguments_example/main.swift#L9-L25" class="">https://github.com/docopt/docopt.swift/blob/master/Examples/Swift/arguments_example/main.swift#L9-L25</a></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""></div><div class="gmail_default" style="font-family:verdana,sans-serif">Docopt does the opposite of what most command line argument libraries do: rather than defining options and auto-generating the help text based on that... You write the help text and it auto-generates a CLI with exactly those options and arguments. It makes writing CLI applications an absolute pleasure, but without multi-line string literals in swift it's currently less pleasant than it could be.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""></div><div class="gmail_default" style="font-family:verdana,sans-serif">Please send me your thoughts. ^_^b</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""></div><div class="gmail_default" style="font-family:verdana,sans-serif">-Travis Tilley</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""></div>
</div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=RC5Cq0zAxCHc1sM9Uy3-2BojrrUAw-2F96zH69NULNHPvCu-2B6nGJajp3QqJqMHepXqY2-2Fb1Xo6V2BckXNFNMRSHOos9iZr55QfCu9aHRhXx97JvJbqwsrqZ8pbbmB3yx4BxYDl7yVDWn7U-2BDT6OorqpMgkN-2BsGANj1EbKmG9fcJs-2FZ93IOsVyfTIa-2BdcnljhISWjktrsSctsgOUBiKEsxH2Q-2FBMwCH4Rbgb2W1cQnOwaIfw-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="">
_______________________________________________<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=""></body></html>