<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="">I'm having trouble getting the `e` modifier to work as advertised, at least for the sequence `\\`. For example, `print(e"\\\\")` prints two backslashes, and `print(e"\\\")` seems to try to escape the string literal. I'm currently envisioning `e` as disabling *all* backslash escapes, so these behaviors wouldn't be appropriate. It also looks like interpolation is still enabled in `e` strings.</div><div class=""><div class=""><br class="">Since other things like `print(e"\w+")` work just fine, I'm guessing this is a bug in the proposal's sketches (not being clear enough about the expected behavior), not your code.<br class=""><br class="">I've written a gist with some tests to show how I expect things to work:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://gist.github.com/brentdax/be3c032bc7e0c101d7ba8b72cd1a692e" class="">https://gist.github.com/brentdax/be3c032bc7e0c101d7ba8b72cd1a692e</a></div></div></blockquote><div><br class=""></div>The problem here is that I’ve not implemented unescaped literals fully as it would require changes outside the lexer.</div><div>This is because the string is first lexed and tokenised by one piece of code <span style="font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures; color: rgb(79, 129, 135);" class="">Lexer</span><span style="font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures;" class="">::lexStringLiteral </span>but later</div><div>on in the code generation phase it generates the actual literal in a function <span style="font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures; color: rgb(79, 129, 135);" class="">Lexer</span><span style="font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures;" class="">::getEncodedStringSegment.</span></div><div>This is passed the same string from the source file but does not know what modifiers should be applied. As a result</div><div>normal escapes are still processed. All the “e” flag does is silence the error for invalid escapes during tokenising.</div><div><br class=""></div><div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #3d1d81" class="">assert</span><span style="font-variant-ligatures: no-common-ligatures" class="">( e</span><span style="font-variant-ligatures: no-common-ligatures; color: #d12f1b" class="">"\w\d+</span><span style="font-variant-ligatures: no-common-ligatures" class="">\</span><span style="font-variant-ligatures: no-common-ligatures; color: #d12f1b" class="">(</span><span style="font-variant-ligatures: no-common-ligatures" class="">author</span><span style="font-variant-ligatures: no-common-ligatures; color: #d12f1b" class="">)\n"</span><span style="font-variant-ligatures: no-common-ligatures" class=""> == </span><span style="font-variant-ligatures: no-common-ligatures; color: #d12f1b" class="">"<a href="smb://w//d+" class="">\\w\\d+</a></span><span style="font-variant-ligatures: no-common-ligatures" class="">\</span><span style="font-variant-ligatures: no-common-ligatures; color: #d12f1b" class="">(</span><span style="font-variant-ligatures: no-common-ligatures" class="">author</span><span style="font-variant-ligatures: no-common-ligatures; color: #d12f1b" class="">)\n"</span><span style="font-variant-ligatures: no-common-ligatures" class=""> );</span></div></div><div><br class=""></div><div>Having encountered this limitation I managed to persuade myself this is what you want anyway but perhaps few would agree,</div><div>What has been implemented is more of an r”” than a e”” that solves the “picket fence” problem where you can also interpolate</div><div>into convenient regex literals. This is all beyond the scope of this proposal anyway so I’ll leave that battle for another day.</div><div>The changes to the compiler for anything else would be a step up in terms of disruption.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">and one new feature that \ before a newline ignores the newline.<br class=""></blockquote><br class="">This is in the "Future directions for multiline strings" section of the proposal. Having implemented this, how do you feel about it? Does it seem like such a no-brainer that we should just incorporate it into the proposal?<br class=""></div></div></blockquote><br class=""></div><div>I agree, lets move it into scope.</div><div><br class=""></div><div>Latest toolchain with the ability to have more than one modifier as you suggest is now:</div><div><font color="#4787ff" class=""><u class=""><a href="http://johnholdsworth.com/swift-LOCAL-2016-05-02-a-osx.tar.gz" class="">http://johnholdsworth.com/swift-LOCAL-2016-05-02-a-osx.tar.gz</a></u></font></div><div><font color="#4787ff" class=""><u class=""><br class=""></u></font></div><div>John</div><br class=""></body></html>