<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="">Am 22.04.2017 um 21:27 schrieb Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Sat, Apr 22, 2017 at 12:57 PM, Thorsten Seitz <span dir="ltr" class=""><<a href="mailto:tseitz42@icloud.com" target="_blank" class="">tseitz42@icloud.com</a>></span> wrote:<br class=""><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" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">Am 22.04.2017 um 17:08 schrieb Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>>:</div><br class="m_-1988748380155040816Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Sat, Apr 22, 2017 at 3:21 AM, Thorsten Seitz <span dir="ltr" class=""><<a href="mailto:tseitz42@icloud.com" target="_blank" class="">tseitz42@icloud.com</a>></span> wrote:<br class=""><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" class=""><br class=""><div class=""><div class=""><div class="m_-1988748380155040816h5"><blockquote type="cite" class=""><div class="">Am 21.04.2017 um 20:48 schrieb Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>>:</div><br class="m_-1988748380155040816m_-8837132544229508421Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Fri, Apr 21, 2017 at 1:45 PM, Erica Sadun <span dir="ltr" class=""><<a href="mailto:erica@ericasadun.com" target="_blank" class="">erica@ericasadun.com</a>></span> wrote:<br 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-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><span class="m_-1988748380155040816m_-8837132544229508421gmail-"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 21, 2017, at 12:40 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_-1988748380155040816m_-8837132544229508421gmail-m_482158630296011926Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Fri, Apr 21, 2017 at 8:48 AM, Robert Bennett via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br 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-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Xiaodi, I think one thing you're neglecting is that users may never print out a multiline literal string at all. A string might never be printed or read by a human outside of the code it resides in. In this case it seems perfectly reasonable to ask that it be possible to format the string nicely in the code and disregard how it would actually be printed.<br class=""></blockquote><div class=""><br class=""></div><div class="">Can you give an example of such a use case, where a string is never seen by a human but one cannot insert literal newlines and would need elided ones instead?</div></div></div></div></div></blockquote><br class=""></div></span><div class="">The most common reason is that the code is maintained by a (non-human) developer, who wants to be able to see and update the code in a readable form, but that represents a single line that will automatically wrapped by, for example, a UITextView for (human) consumption. </div></div></blockquote><div class=""><br class=""></div><div class="">A different scenario from what Robert's describing, but sure. This goes to my question to David Hart. Isn't this an argument for a feature to allow breaking a single-line string literal across multiple lines? What makes this a use case for some feature for _multiline_ string literals in particular?</div></div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div class="">I think „single-line“ and „multiline“ should foremost apply to the code representation of a string and not its result.</div><div class="">Otherwise "foo\nbar“ would be a multiline string with your reasoning, wouldn’t you agree?</div></div></div></blockquote><div class=""><br class=""></div><div class="">I think Robert Bennett has summarized the differences between his view and my view of literals very well. Keep in mind we're talking about _string literals_, not strings. To me, a literal is something that represents its data as literally as possible. Therefore, what makes something a _multiline_ string literal is simple: it permits literal newlines.</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I know that we are talking about string literals, not strings, that’s why I talked about _representations_ vs. _results_. </div><div class=""><br class=""></div><div class="">A literal is a _textual representation_ of data as opposed to a calculation. Requiring for the special case of _string_ literals that the textual representation has to be as literal as possible is an artificial restriction that I do not share. </div><div class="">Following your argument you would have to prohibit `\t` and `\n` from multiline strings and `\t` from single-line strings because these characters can be written literally and therefore should (to be represented "as literally as possible“).</div><div class=""><br class=""></div><div class="">So, to reiterate, the valuable distinction between single-line and multiline string literals is their textual representation and *not* whether the result of that has one or more lines. Multiline strings allow easier maintenance of _long_ strings (which may or may not have multiple lines). </div></div></div></blockquote><div class=""><br class=""></div><div class="">I have never argued that the distinction between single-line and multiline string literals is whether the resulting string has one or more lines. I have argued that a multiline string literal is _a string literal which permits literal newlines_.</div><div class=""><br class=""></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" class=""><div class=""><div class="">And just as `\n` is allowed in single-line string literals resulting in a multiline string it would make sense to allow `\` in multiline string literals to suppress literal newlines.</div><div class="">The result would be </div><div class="">(a) single-line string literals which are always written in a single line but can represent single-line or multiline strings (just as today, using `\n`) and </div><div class="">(b) multiline string literals which are always written in multiple lines but can equally represent single-line (not possible today) or multiline strings (using literal newlines or `\n`).</div></div></div></blockquote><div class=""><br class=""></div><div class="">It _is_ currently possible for a multiline string literal to represent a single-line string:</div><div class=""><br class=""></div><div class="">'''</div><div class="">This is a single-line string using multiline string literal syntax. You can soft-wrap this as much as you want. An intelligent editor might even indent the soft-wrapping in a pretty but unambiguous way.</div><div class="">'‘'</div></div></div></div></div></blockquote><div><br class=""></div><div>You seem to be choosing to deliberately ignore what I (and others) write, so I will tell you a last time that hard wrapping is important to maintenance of long literal strings, because soft-wrapping is no solution due to indentation and no, an intelligent editor is not a solution either because code is not only viewed in an intelligent editor.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></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" class=""><div class=""><div class="">A notable difference between single-line string literals and multiline string literals is that whitespace is not visible anymore at the end of each line (as has been pointed out several times by Adrian). Within a single-line string literal whitespace is visible everywhere within the string. Within a multiline string literal whitespace is visible at the beginning of each line due to the position of the closing delimiter and the corresponding indentation suppression, it is visible within each line but it is *not* visible at the end of a line. That would be fixed by suppressing trailing whitespace and only allowing it before a `\`.</div><div class="">This is similar to the normalization of the literal newline to `\n`.</div><div class=""><br class=""></div><div class="">Pointing to tools or editor features to strip trailing whitespace is simply *wrong* IMHO because the idea of stripping trailing whitespace by editors or tools is only intended for *non-relevant* whitespace!</div><div class="">How often have you worked in teams where each developer has different settings for his editor (if they even use the same editor)? Relying on this will lead to stripping of relevant whitespace because someone has opened the file with the stripping setting on in his editor — and the problem is that this change is not even visible.</div></div></div></blockquote><div class=""><br class=""></div><div class="">This argument is problematic. Is your position that literal trailing whitespace in a multiline string literal is *relevant* or *non-relevant*?</div></div></div></div></div></blockquote><div><br class=""></div>Relevant, of course. That is why it is to be protected from tools and to be made visible.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">If literal trailing whitespace in a multiline string literal is *relevant*, then neither should your tools strip them away nor should the compiler suppress them.</div></div></div></div></div></blockquote><div><br class=""></div><div>Yep, but tools commonly *do* offer to strip trailing whitespace because — up to now — trailing whitespace was irrelevant to code for all languages that I know. </div><div>That is exactly why relevant trailing whitespace has to be protected by a backslash like I explained at length. Effectively the trailing backslash marks which trailing whitespace is relevant by making it non-trailing :-)</div><div><br class=""></div><div>There is no way around it: tools expect trailing whitespace to be irrelevant.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">If literal trailing whitespace in a multiline string literal is *irrelevant*, then it does not matter whether or not your tools strip them away and it does not matter whether or not the compiler suppresses them.</div><div class=""> <br class=""></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" class=""><div class=""><div class="">In another mail you pointed out that Unicode makes relying on visible characters difficult anyway. While that is true, I think there is a significant difference between characters that I _see_ which might not have the correct character code and characters that I _do not even see_.</div></div></div></blockquote><div class=""><br class=""></div><div class="">In Unicode, there are many, many code points you do not see. These have large security implications. It is simply false to say that stripping trailing whitespace will allow you to see some representation of each code point that is present in the string. It absolutely will not. It cannot be possible that trailing spaces are a problem for you, </div></div></div></div></div></blockquote><div><br class=""></div><div>Yes it can. Curiously I didn’t have the need for non-breaking spaces or half-width spaces yet, but do commonly make use of spaces and tabs.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">but trailing non-breaking spaces or trailing half-width spaces are not a problem.</div></div></div></div></div></blockquote><div><br class=""></div><div>The same problem and solution applies to trailing non-breaking spaces and half-width spaces. I might not easily see whether a space is breaking or non-breaking but at least I will see that there is one in the first place.</div><div><br class=""></div><div>-Thorsten</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></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" class=""><div class=""><span class="HOEnZb"><font color="#888888" class=""><div class="">-Thorsten</div></font></span><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </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" class=""><div class=""><div class="">Therefore a multiline string is one which is written over several lines of *code* to make maintenance easier. </div><div class="">From that follows naturally that as soon as line breaks are introduced for hard wrapping we are talking about multiline strings.</div><div class=""><br class=""></div><div class="">In addition as soon as line breaks are introduced in the code the question of indentation arises which is solved neatly with the multiline string proposal by the position of the ending delimiter which is not possible with single-line strings. </div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class="m_-1988748380155040816HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">-Thorsten</div><div class=""><br class=""></div></font></span></div></div></blockquote></div><br class=""></div></div>
</div></blockquote></span></div><br class=""></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>