<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>From Joe's email:</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">"[...]</div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">Discussion on the list raised the idea of allowing a line to end with \ to "escape" the newline and elide it from the value of the literal; the core team had concerns about only allowing that inside multi-line literals and felt that that could also be considered later as an additive feature.</span></div><div id="AppleMailSignature">[...]"</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">So it sounds that can be considered in a separate proposal to be added to normal and multi-line string literals. <br><br><br></div><div><br>On Apr 21, 2017, at 2:57 PM, Xiaodi Wu 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">On Fri, Apr 21, 2017 at 1:46 PM, David Hart <span dir="ltr"><<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><div><br></div><div>On 21 Apr 2017, at 20:20, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Fri, Apr 21, 2017 at 8:45 AM, David Hart <span dir="ltr"><<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On 21 Apr 2017, at 11:32, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-9164707683686196204m_5119260798833980300Apple-interchange-newline"><div><div class="m_-9164707683686196204m_5119260798833980300bloop_markdown" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)"><p style="margin:15px 0px">Dear Xiaodi Wu, why do you always have to be offensive in a way of questioning every single word another person says and not letting others to have their own opinion?! I do not want to have a discussion with you that will and up you asking me why is the banana crooked. I expect a focused and a constructive discussion if not mentioned otherwise.</p><p style="margin:15px 0px">My expectation from the model of the multi-lined string literal might be different from yours and you’ll have to bear with that, because I’ve got my own opinion. If you’d like me to see things differently, try to convince me instead of being unfocused and questioning every single word I’m saying. That won’t lead use to anywhere.</p></div></div></blockquote></span><div>Hi Adrian. For what it's worth, I did not detect any offense in Xiaodi’s questions. I think he was just asking questions to point parts of your opinion which he did not understand or was missing some reasoning.</div></div></div></blockquote><div><br></div><div>Yes, that was my intention.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><blockquote type="cite"><div><div class="m_-9164707683686196204m_5119260798833980300bloop_markdown" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)"><p style="margin:15px 0px">I expect the model to solve two major problems. The first one is already solved by the accepted version. The second one is the ability to escape new lines when needed (notice, I do not want to escape them all the time, but only where it’s desired). The accepted version adds more possibilities to the language and will definitely fix a lot of pain with string literals some developer had. I’m happy to see that. However from my personal standpoint, I do not write any code generators created from string literals as it was a heavily overused example in the proposal and during the discussion. I often need the ability to wrap very long strings into multiple lines for readability, but keep the result string intact. In my last response I showed a sample on how it might look like and that it’s really painful to read such a string on Git, because it does not provide any soft-wrapping like other tools might do. That is why I keep saying that the multi-line string literal should not rely on editors to solve that problem. Otherwise the bare existence of the such literal could be questioned and we could fully fall back to editor features like soft-wrapping or let the editor also wrap strings when it finds a new line character<span class="m_-9164707683686196204m_5119260798833980300Apple-converted-space"> </span><code style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal">\n</code><span class="m_-9164707683686196204m_5119260798833980300Apple-converted-space"> </span>to mimic the proposed behavior. I also do not like the argument of using string concatenation to solve my particular issue, because the strings are very long and it quickly becomes were tedious. Furthermore, the multi-line string literal should not be only reserved for solving the problems you’ve mentioned. A trailing backslash does not add any complexity, and you personally don’t need that feature it does not mean that others won’t need it. It’s an additional feature which is lightweight and which won’t harm the copy-paste phenomenon most of you wanted. If you really think it adds complexity than you should also justify your thoughts to convince your conversation partner.<span class="m_-9164707683686196204m_5119260798833980300Apple-converted-space"> </span></p><p style="margin:15px 0px">IMHO ‘complexity’ creates ‘flexibility’. If we’d only had one access modifier in Swift the model would be really simple but not flexible. Not that we have a bunch of them the model become complex but on the other hand it also become way more flexible.</p></div></div></blockquote></span><div>But for what its worth, I agree with Adrian. Let me try to expose the use-case the proposal is not addressing:</div><div><br></div><div>A group of people (me included) don’t wrap lines in their editor (by choice) but make sure that lines of code don’t extend over a certain limit (80, 100, 120, whatever). This allows us to keep code readable and control the wrapping behaviour by manually applying it.</div><div><br></div><div>For those people, writing long prose which extends over our limit (like is the case in some error/assert/precondition messages), we won’t be able to use the multi-line string proposal and we will have to stay with string concatenation:</div></div></div></blockquote><div><br></div><div>But the key questions I asked are still unanswered:</div><div><br></div><div>- What is wrong with string concatenation? Why is that not the ideal solution? A key motivation for this particular proposal was that it will allow you to copy and paste content with newlines into a string. But here, you are explicitly wrapping a string without newlines for the purposes of formatting your own code. Surely, that can be just as easily done by writing `"+"` as it is by writing `\`, no?</div></div></div></div></div></blockquote><div><br></div></span><div>The reason I'm bothered about string concatenation is that it's not as easily maintainable. For example, imagine I modify some text in one of the segments (before the last). I have to re-evaluate where the separation will go and do more editing than with \.</div></div></blockquote><div><br></div><div>Hmm...the difficulty of editing hard-wrapped strings is principally due to the hard-wrapping and not the delimiters, wouldn't you say? I've manually re-wrapped my share of hard-wrapped text *without* delimiters, and it's sufficiently a pain in the butt. Yes, there are three characters in `"+"` to add or delete instead of the one in `\`, but the crux of the issue is the hard-wrapping, which you're _choosing_ to do, wouldn't you agree?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>- What does this use case have to do with _multiline_ strings? Put another way, why are you in support of a syntax for line continuation, but only for _multiline_ string literals? [Looking back, I guess this echoes one of the core team's issues with it as well.] In your examples, you're demonstrating that it's very useful for generating _single-line_ strings. If this is a common use and important use case, shouldn't we be designing a way to make this work with _single-line string literals_?</div></div></div></div></div></blockquote><div><br></div></span><div>The only link with multi-line string with my example is that we are choosing to format it over multiple lines of source code. But of course, I wouldn't be against a special syntax of single-line strings to solve the same problem:</div><div><br></div><div>assert(condition, "A single-line string over multiple lines</div><div> could look like this - new lines are ignored")</div></div></blockquote><div><br></div><div>And this is my point. If this feature is worth having, then whatever syntax it goes by, it has nothing to do with multiline string literals and should work for all string literals. It's simply not part and parcel of multiline string literals.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div class="h5"><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>One argument left unsaid here, but which I guess I'll state explicitly: in the decisions that they have taken on review, the core team has, afaict, shown that they want to design "multiline string literals" in such a way that a multiline (string literal) is the preferred way of spelling a (multiline string) literal, and that the latter should be the principal use for the former. I think this is both wise and worthy of preservation, unless there is some very strong countervailing reason.</div><div><br></div><div>But anyway, we are getting far afield here. I don't feel particularly strongly about `\` as a feature here. But I do believe that making trailing whitespaces at the end of a line a compiler warning or error is not the way to go. Either your style is to strip those out and you already have tools to enforce that, or it isn't your style and the compiler shouldn't force you to. The idea that it must be possible to visually inspect a string and know what characters are contained in it is not only unhelpful but dangerous: with Unicode, this "inspectability" can never be guaranteed, and making gestures at solving only one particular example of the issue would encourage users to rely on visual inspection of strings when they absolutely should not.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>Taking the following piece of code:</div><div><br></div><div><font face="Menlo">func myFunction() {</font></div><div><font face="Menlo"> assert(aVariable > 10 && anotherVariable < 50, “Variables `aVariable` and `anotherVariable` are outside their expected range. Please check that your are not calling this function around midnight”)</font></div><div><font face="Menlo">}</font></div><div><br></div><div>I currently write it using string concatenation:</div><div><br></div><div><div><font face="Menlo">fun myFunction() {<br> assert(aVariable > 10 && anotherVariable < 50, "Variables `aVariable` and `anotherVariable` " +</font></div><div><font face="Menlo"> "are outside their expected range. Please check that your are not calling this function " +<br> "around midnight")<br>}</font></div><div><br></div><div>But writing it using the multi-line string syntax:</div><div><br></div><div><font face="Menlo">fun myFunction() {<br> assert(aVariable > 10 && anotherVariable < 50, """Variables `aVariable` and `anotherVariable` </font></div><div><font face="Menlo"><span class="m_-9164707683686196204m_5119260798833980300Apple-tab-span" style="white-space:pre-wrap"> </span>are outside their expected range. Please check that your are not calling this function </font></div><div><font face="Menlo"><span class="m_-9164707683686196204m_5119260798833980300Apple-tab-span" style="white-space:pre-wrap"> </span>around midnight<br> """)<br>}</font></div><div><br></div><div>will inject unwanted newlines. I think what we would like to be able to do is:</div><div><br></div><div><div><font face="Menlo">fun myFunction() {<br> assert(aVariable > 10 && anotherVariable < 50, """Variables `aVariable` and `anotherVariable` \</font></div><div><font face="Menlo"><span class="m_-9164707683686196204m_5119260798833980300Apple-tab-span" style="white-space:pre-wrap"> </span>are outside their expected range. Please check that your are not calling this function \</font></div><div><font face="Menlo"><span class="m_-9164707683686196204m_5119260798833980300Apple-tab-span" style="white-space:pre-wrap"> </span>around midnight<br> """)<br>}</font></div><div><font face="Menlo"><br></font></div><div>Notice how the space at the end of the line is also quite obvious now.</div></div></div><div><div class="m_-9164707683686196204h5"><br><blockquote type="cite"><div><div class="m_-9164707683686196204m_5119260798833980300bloop_original_html" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)"><div id="m_-9164707683686196204m_5119260798833980300bloop_sign_1492765049485778944" class="m_-9164707683686196204m_5119260798833980300bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div><br><p class="m_-9164707683686196204m_5119260798833980300airmail_on" style="margin:15px 0px">Am 20. April 2017 um 21:50:27, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank">xiaodi.wu@gmail.com</a>) schrieb:</p><blockquote type="cite" class="m_-9164707683686196204m_5119260798833980300clean_bq" style="margin:15px 0px"><span style="margin-top:0px;margin-bottom:0px"><div><div></div><div><div dir="ltr">On Thu, Apr 20, 2017 at 11:48 AM, Adrian Zubarev<span class="m_-9164707683686196204m_5119260798833980300Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:adrian.zubarev@devandartist.com" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank">adrian.zubarev@devand<wbr>artist.com</a>></span><span class="m_-9164707683686196204m_5119260798833980300Apple-converted-space"> </span>wrote:<br><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-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word"><div class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824bloop_markdown"><p style="margin:15px 0px">The multi-line string literal as it’s accepted right now only allows pretty code generation with smaller lines.</p></div></div></blockquote><div><br></div><div>This statement does not make sense to me. Multiline string literals allow (with the unavoidable exception of some escape sequences) code written inside the quotations marks to be exactly as pretty as the resulting string itself. That is why it's a literal.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word"><div class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824bloop_markdown"><p style="margin:15px 0px">The literal itself is not reserved for JSON, XML and similar syntaxes only, which automatically implies the existence of conventions with longer lines. For whatever reasons a developer might have, it’s essential to allow manual line wrapping without injecting a new line into the resulting string.</p></div></div></blockquote><div><br></div><div>You keep re-stating instead of explaining why you think this is essential. What are the "whatever reasons" for a developer to need this feature? It is critical enough to be worth complicating the design for something like literal syntax, which should be as lightweight, straightforward, and simple as possible?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word"><div class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824bloop_markdown"><p style="margin:15px 0px">Not everyone uses the same editor width nor the same editor with exact the same settings.</p></div></div></blockquote><div><br></div><div>Do you think it is a common use case that someone will want to have text that looks the same only to people reading the code, but not to people reading the resulting string? Do you think someone might want to put code inside a string literal, then wrap the literal using 80-character lines, but write the code inside to wrap using 120-character lines? These seem like rather implausible use cases.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word"><div class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824bloop_markdown"><p style="margin:15px 0px">You simply cannot and really should not rely on any editor or linter for that matter,</p></div></div></blockquote><div><br></div><div>If you are going to view a Swift file, you're going to do it through some program or other. Is it reasonable to add features to Swift because some hypothetical text editors might not be able to wrap lines? </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word"><div class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824bloop_markdown"><p style="margin:15px 0px">nor do I vision it as a strong argument against having the ability to escape the new line injection. I don’t think we should ever expect the average Swift developer sitting in-front of an ultra wide monitor.</p><p style="margin:15px 0px">Consider this example:</p><pre style="margin:15px 0px;font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(204,204,204);overflow:auto;padding:4px 8px;word-break:normal;word-wrap:normal"><code class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824swift" style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:0px;margin:0px;padding:0px;word-break:normal;word-wrap:normal">// Currently it would look like this:
let myLongString = "Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.\n\nNam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming id quod mazim placerat facer possim assum. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.\n\nDuis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis."
// With the accepted version of the proposal it becomes a little bit better, but still to long,
// because we can only replace `\n` characters with lines and that's it.
let myLongString = """
Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.
Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming id quod mazim placerat facer possim assum. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.
Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis.
"""
// This is how it should ideally look like and be editor/IDE/linter independent.
// The string produces the same result as above and does not rely on any
// soft-wrapping functionality</code></pre></div></div></blockquote><div><br></div><div>Why should one not rely on editors being able to soft wrap? Which editors cannot soft wrap? What is wrong with soft wrapping?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word"><div class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824bloop_markdown"><pre style="margin:15px 0px;font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(204,204,204);overflow:auto;padding:4px 8px;word-break:normal;word-wrap:normal"><code class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824swift" style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:0px;margin:0px;padding:0px;word-break:normal;word-wrap:normal"> and is written within some smaller line width.
// The trailing precision is a really good tradeoff at this point.
let myLongString = """
Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit \
lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure \
dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore \
eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui \
blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.
Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming \
id quod mazim placerat facer possim assum. Lorem ipsum dolor sit amet, consectetuer \
adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna \
aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation \
ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.
Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie \
consequat, vel illum dolore eu feugiat nulla facilisis.
"""
</code></pre><hr style="height:0.2em;border:0px;color:rgb(204,204,204);background-color:rgb(204,204,204);display:inherit"><p style="margin:15px 0px">The string concatenation uses optimization magic behind the scenes which is not obvious for everyone.</p></div></div></blockquote><div><br></div><div>What is magic about string concatenation?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word"><div class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824bloop_markdown"><p style="margin:15px 0px">I personally think that every operation involved in concatenation or any operation in-general adds a performance overhead</p></div></div></blockquote><div><br></div><div>In what scenarios have you encountered runtime performance bottlenecks due to concatenation of string literals?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word"><div class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824bloop_markdown"><p style="margin:15px 0px">and theoretically needs more time to resolve the expression at runtime, which is the natural way of thinking without any knowledge</p></div></div></blockquote><div><br></div><div>Why should we add new features simply because people who "think without any knowledge" might have misunderstandings about existing ones?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word"><div class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824bloop_markdown"><p style="margin:15px 0px">about the optimization the compiler is able to do for you. A string literal is able to solve that issue during compile time is simply the perfect place for that.</p></div></div></blockquote><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word"><div class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824bloop_markdown"><hr style="height:0.2em;border:0px;color:rgb(204,204,204);background-color:rgb(204,204,204);display:inherit"><p style="margin:15px 0px">Some words about the trailing precision. Joe said that we could use<span class="m_-9164707683686196204m_5119260798833980300Apple-converted-space"> </span><code style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal">\("")</code><span class="m_-9164707683686196204m_5119260798833980300Apple-converted-space"> </span>as workaround, but if I recall correctly literals are banned from the interpolation itself, which will result in us doing something like this:</p><pre style="margin:15px 0px;font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(204,204,204);overflow:auto;padding:4px 8px;word-break:normal;word-wrap:normal"><code class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824swift" style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:0px;margin:0px;padding:0px;word-break:normal;word-wrap:normal">let end = ""
let myString = """
<space><space>foo<space><space<wbr>>\(end)
"""
</code></pre><p style="margin:15px 0px">This is a very dirty and tedious solution for that problem.</p><p style="margin:15px 0px">As accepted right now, no one should ever expect the result string to include any whitespace characters at the end of each line unless there is a visible annotation provided for precision.</p></div></div></blockquote><div><br></div><div>Why shouldn't they? I expect nothing about line endings with the current accepted design. Why should I expect literal whitespace to be visibly annotated? I expect them to be, um, whitespace.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word"><div class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824bloop_markdown"><p style="margin:15px 0px">Providing a warning for trailing whitespace characters would be ideal solution right now and the trailing backslash becomes additive but not impossible to add later.</p><hr style="height:0.2em;border:0px;color:rgb(204,204,204);background-color:rgb(204,204,204);display:inherit"><p style="margin:15px 0px">A few people already argued that the core team decided not to include a new line at the end of each multi-line string, where you yourself said that the absence of a trailing backslash will produce a string which always ends with a new line. That behavior would be really strange and painful to prevent if there is no backslash for escaping it.</p><p style="margin:15px 0px">The trailing backslash does not add any complexity but instead it adds more flexibility to the literal model, which results in better readability if the precision is desired for code formatting!</p></div><div class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824bloop_original_html"><div id="m_-9164707683686196204m_5119260798833980300m_8772741926274410824bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px"><span><br></span></div><span><br></span><div id="m_-9164707683686196204m_5119260798833980300m_8772741926274410824bloop_sign_1492706130704740096" class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824bloop_sign"><div style="font-family:helvetica,arial;font-size:13px"><span>-- <br>Adrian Zubarev<br>Sent with Airmail</span></div></div><span><br></span><div><div class="m_-9164707683686196204m_5119260798833980300h5"><p class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824airmail_on" style="margin:15px 0px">Am 20. April 2017 um 07:30:29, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank">xiaodi.wu@gmail.com</a>) schrieb:</p><blockquote type="cite" class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824clean_bq" style="margin:15px 0px"><div style="margin-top:0px;margin-bottom:0px"><div><span>You can use a plain text editor and no linter, or a plain text editor and a linter, or an IDE and no linter, etc., and in any of these scenarios you can already choose whether or not you want trailing newlines stripped. Why should the compiler try to enforce any rules here?<br><br></span><div><span>Since Unicode is supported, it is never possible to look at a string literal and be 100% sure of what glyphs are involved. We should be clear that such a criterion cannot and should not be a design goal. If it supports Unicode and is really literal, then confusables and invisibles will make it impossible to be sure of what you see; you would have to either stop supporting Unicode or stop being literal.<br><br>I'm not sure this "coding style" you describe can properly be thought of as a multiline string literal. It sounds like what you want isn't multiline (in fact, you want a new way to write a very long single-line string) and it isn't literal (you want to use newlines in your code that do not represent a literal newline). If there is something extremely critical about a particular string, where you simply must start half of it on a separate line to help the readers of your code understand what you are doing, you can already do this by writing "foo" + [newline] "bar". Or you could just let your editor soft-wrap your long string. Making your single-line string wrap the same way in every IDE just doesn't seem like it's related to or worth complicating the syntax for multiline string literals. I would be strongly opposed to such a feature.</span></div><div><span><br><br></span><div class="gmail_quote"><div><span>On Wed, Apr 19, 2017 at 23:42 Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank">swift-evolution@swift.org</a>> wrote:<br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;word-wrap:break-word"><div class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824m_-6208984668242159980m_3629141258267239431bloop_markdown"><p style="margin:15px 0px"><span>True, but this is not about IDEs or editors. The feature itself doesn’t know what an editor is and what it capable of, nor should be ever rely on that. Not everyone uses the same settings and you cannot be 100% sure to expect the same string from looking at it, which was written in a different editor if we don’t warn about trailing whitespaces now.</span></p><p style="margin:15px 0px"><span>The trailing whitespaces might not do any harm for the currently accepted version, but we’ll have to warn about them if we decide to add the trailing backspace. As currently accepted we still have a hole to fill for coding styles, we do not support multi-lined string literals for code formatting only, nor do we have trailing precision for the same matter. (That’s what the backslash was meant for.) That said, I cannot break up a really long hardcoded string, which in my IDE is softly wrapped, into a multi-line string literal so that it looks in every editor the same and still expect the same result and be precise about the trailing whitespace characters.</span></p></div><div class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824m_-6208984668242159980m_3629141258267239431bloop_original_html"></div></div><div style="word-wrap:break-word"><div class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824m_-6208984668242159980m_3629141258267239431bloop_original_html"><div id="m_-9164707683686196204m_5119260798833980300m_8772741926274410824m_-6208984668242159980m_3629141258267239431bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px"><span><br></span></div><span><br></span><div id="m_-9164707683686196204m_5119260798833980300m_8772741926274410824m_-6208984668242159980m_3629141258267239431bloop_sign_1492662767413933056" class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824m_-6208984668242159980m_3629141258267239431bloop_sign"><div style="font-family:helvetica,arial;font-size:13px"><span>-- <br>Adrian Zubarev<br>Sent with Airmail</span></div></div><span><br></span></div></div><div style="word-wrap:break-word"><div class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824m_-6208984668242159980m_3629141258267239431bloop_original_html"><p class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824m_-6208984668242159980m_3629141258267239431airmail_on" style="margin:15px 0px"><span>Am 20. April 2017 um 00:27:48, Brent Royal-Gordon via swift-evolution (<a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank">swift-evolution@swift.org</a>) schrieb:</span></p></div></div><div style="word-wrap:break-word"><div class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824m_-6208984668242159980m_3629141258267239431bloop_original_html"><blockquote type="cite" class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824m_-6208984668242159980m_3629141258267239431clean_bq" style="margin:15px 0px"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word"><div><div><blockquote type="cite" style="margin:15px 0px"><div style="margin-top:0px"><span><span>On Apr 19, 2017, at 3:18 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank">swift-evolution@swift.org</a>> wrote:</span></span></div><span><br class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824m_-6208984668242159980m_3629141258267239431Apple-interchange-newline"></span><div style="margin-bottom:0px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word"><div><div><span>Other common tools like Git already flag trailing whitespace by default, so even if Swift doesn't warn about it, you might still need to satisfy other tools in your pipeline.</span></div></div></div></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span><br></span></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span>Isn't that an equally good argument for Swift *not* warning you about it? If it's harmful, you'll have other tools in the pipeline to flag it for you.</span></div></div></blockquote></div><div><span><br></span></div><div><span>Cosigned. We already have an Xcode setting to strip trailing whitespace, a Git setting to flag it, and linter settings to remove it. (For instance, SwiftFormat has a --trimwhitespace flag.) Not every tool needs to handle every case of questionable style.</span></div><span><br></span><div><div><div style="font-size:12px"><span><span class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824m_-6208984668242159980m_3629141258267239431Apple-style-span" style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-variant-east-asian:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">-- </span></span></div><div style="font-size:12px"><span class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824m_-6208984668242159980m_3629141258267239431Apple-style-span" style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-variant-east-asian:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Brent Royal-Gordon</span></div><div style="font-size:12px"><span class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824m_-6208984668242159980m_3629141258267239431Apple-style-span" style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-variant-east-asian:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Architechies</span></div></div></div><br></div></div></blockquote></div></div><div style="word-wrap:break-word"><div class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824m_-6208984668242159980m_3629141258267239431bloop_original_html"><blockquote type="cite" class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824m_-6208984668242159980m_3629141258267239431clean_bq" style="margin:15px 0px"><div style="margin-top:0px;margin-bottom:0px;word-wrap:break-word"><div><span>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br></span></div></div></blockquote></div></div>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br style="margin-bottom:0px"></blockquote></div></div></div></div></blockquote></div></div></div><div class="m_-9164707683686196204m_5119260798833980300m_8772741926274410824bloop_markdown"></div></div></blockquote></div><br></div></div></div></div></span></blockquote></div><div class="m_-9164707683686196204m_5119260798833980300bloop_markdown" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)"><div style="margin:15px 0px"><br class="m_-9164707683686196204m_5119260798833980300webkit-block-placeholder"></div></div><span style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254);float:none;display:inline!important">______________________________<wbr>_________________</span><br style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)"><span style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254);float:none;display:inline!important">swift-evolution mailing list</span><br style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)"><a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:rgb(254,254,254);text-decoration:none;font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">swift-evolution@swift.org</a><br style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color:rgb(65,131,196);background-color:rgb(254,254,254);text-decoration:none;font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)"></div></blockquote></div></div></div><br></div></blockquote></div><br></div></div>
</div></blockquote></div></div></div></blockquote></div><br></div></div>
</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>