<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPhone</div><div><br>On Dec 10, 2015, at 1:56 PM, Travis Tilley via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><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 class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">My initial improvement request is here: <a href="https://bugs.swift.org/browse/SR-170">https://bugs.swift.org/browse/SR-170</a></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default"><font face="verdana, sans-serif">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 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"><br></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></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></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: <a href="https://github.com/docopt/docopt.swift/blob/master/Examples/Swift/arguments_example/main.swift#L9-L25">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></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></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></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></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></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div>
</div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=rNAQL0AKA4cYVFbcsxm28gp053gl0wHSve0gUfy9y4ldZQTmhnB5fSM88gLHiNmcEK-2BnrLcyC3Zv2e1KlK-2BmmB13jyIjpz4akyrCYeuT7AdvrNo6FD-2BPZOKbtQd3V258A1KuhW2I6WosYkOECkFz3I7DYCsr2vgJMxx9OwY7azKkWUTRoWhmTC8kbIx7P0bmOu89EQk1Ct7AyFmTyP-2BT-2Bw-3D-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;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>