<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="">On Dec 10, 2015, at 6:01 PM, Travis Tilley &lt;<a href="mailto:ttilley@gmail.com" class="">ttilley@gmail.com</a>&gt; wrote:<br class=""><div><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><br class=""></div><div>Yes, I agree that should be the default.</div><div><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?&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></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><br class=""></div><div>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&nbsp;styles IIRC?) with different policies. &nbsp;One&nbsp;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>. &nbsp;In some dialects of inline assembly in C, for example, this can lead to very ugly code.</div><div><br class=""></div><div>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><br class=""></div><div>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. &nbsp;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. &nbsp;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></body></html>