<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=""><div class="">In the OP, Travis wrote:</div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class="">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. </blockquote></div></div><div class=""><br class=""></div><div class="">Ruby has … oh, on the order of 2^9 different string syntaxes, but none of them address this indentation problem, and it’s a constant complaint. Hacks for it abound.</div><div class=""><br class=""></div><div class="">• • • </div><div class=""><br class=""></div><div class="">In Ruby in the wild, off the top of my head and totally unscientifically, the most widely-used flavors I’ve seen are the heredoc with interpolation and terminator indentation:</div><div class=""><br class=""></div><div class=""><div class=""> string = <<-EOS</div><div class=""> gone is music</div><div class=""> yet you sing</div><div class=""> EOS</div></div><div class=""><br class=""></div><div class="">…and just putting newlines inside a double-quoted string:</div><div class=""><br class=""></div><div class=""><div class=""> string = "</div><div class=""> gone is music</div><div class=""> yet you sing</div><div class=""> "</div></div><div class=""><br class=""></div><div class="">…probably in that order.</div><div class=""><br class=""></div><div class="">Useful notes on the heredoc variants, typical of Ruby’s “the more syntaxes the merrier!” approach to things:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="http://blog.jayfields.com/2006/12/ruby-multiline-strings-here-doc-or.html" class="">http://blog.jayfields.com/2006/12/ruby-multiline-strings-here-doc-or.html</a></div><div class=""><br class=""></div><div class="">Cheers, P</div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 10, 2015, at 11:02 PM, Chris Lattner 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="">On Dec 10, 2015, at 6:01 PM, Travis Tilley <<a href="mailto:ttilley@gmail.com" class="">ttilley@gmail.com</a>> wrote:<br class=""><div class=""><blockquote type="cite" class="">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?<br class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="gmail_default" style="font-family:verdana,sans-serif">I would want multi-line string literals to behave as much like normal string literals as possible for consistency. To optimize for developer happiness, to steal the ruby saying, unexpected behavior should be kept to a minimum. If \n works in a normal string literal, it should work in a multi-line string literal... even if you could just hit enter instead.</div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Yes, I agree that should be the default.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class="">3) What other policy decisions make sense to expose on these literals? 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></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="gmail_default" style="font-family:verdana,sans-serif">I would have to depend entirely on you to inform me of both these knobs and use cases. I'd love to hear about them, that's for sure.</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">The reason I raise the question is that some languages have multiple quote styles (Perl 5 has something like 3 or 4 different string literal styles IIRC?) with different policies. One reason for this is to disable processing of escapes: if you’re using string literals to enter something that uses \ or “ frequently, it can be irritating and ugly to have a lot of <a href="smb://'s" class="">\\'s</a>. In some dialects of inline assembly in C, for example, this can lead to very ugly code.</div><div class=""><br class=""></div><div class="">When introducing a feature like this, I think it would be useful to survey a range of popular languages (and yes, even perl ;-) to understand what facilities they provide and why (i.e. what problems they are solving) and synthesize a good swift design that can solve the same problems with a hopefully simple approach.</div><div class=""><br class=""></div><div class="">I haven’t looked into this area deeply myself, so I can’t give you a recipe to just follow, some research is required :)<br class=""><br class=""><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><div class="gmail_default" style="font-family:verdana,sans-serif">My initial goal was the minimal possible work required to decrease the noise of writing large blocks of multi-line text and not have to poke around too much in the lexer and parser code (being completely unfamiliar with the swift codebase, having it just become open source recently).</div></div></div></div></div></blockquote></div><br class=""><div class="">Understood, but our first goal is to get the best solution, independent of implementation complexity. In this case, I suspect that the hard part in this feature is scoping it out and hashing out the right design with the community. I can’t imagine that we’d end up with a design that is that difficult to implement in any case.</div><div class=""><br class=""></div><div class="">-Chris</div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=zCg-2FSGF9Wk188a6c55kLyEbrj7YhaXxFEHM-2F-2B0YAlzX957ydoHmkP0ga3-2F19PNUEVaY8eY5-2BPE5nAgtDfELodDAL9O3PSUrr-2BYw-2FSw4AU0HPTbzol7MO-2FrS6WYAIiQB-2B4WVvAUcgAhvZehbpYW4vPSccjzhj9hO8X4kJ88fwMD6AyXD-2F-2FU3J398rNcX-2BD33SErjnSMwCIrZeYDmCbLmWgh5MnkIVDbUfeMualpCklcU-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="">
</div>
_______________________________________________<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>