<div dir="ltr">On Sat, Apr 22, 2017 at 3:58 PM, Thorsten Seitz <span dir="ltr">&lt;<a href="mailto:tseitz42@icloud.com" target="_blank">tseitz42@icloud.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><div style="word-wrap:break-word"><div><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><div><font color="#222222">&lt;snip&gt;</font></div></div></div></div></div></div></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><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><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>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>The result would be </div><div>(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>(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><br></div><div>It _is_ currently possible for a multiline string literal to represent a single-line string:</div><div><br></div><div>&#39;&#39;&#39;</div><div>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></div><div>&#39;‘&#39;</div></div></div></div></div></blockquote><div><br></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></div></div></blockquote><div><br></div><div>I don&#39;t doubt that you in particular do not like soft wrapping. But repeating &quot;hard wrapping is important&quot; is not an argument; it&#39;s just an assertion, and the salient questions are, _how_ important is it really? what should be the design to support such a feature? are the drawbacks of the design outweighed by the degree of importance of hard wrapping?</div><div><br></div><div>Put simply, I am skeptical that hard wrapping is so important that it alone is worth a complicated new set of rules, and no one has offered evidence to the contrary.</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 class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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>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>This is similar to the normalization of the literal newline to `\n`.</div><div><br></div><div>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>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><br></div><div>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></div></span>Relevant, of course. That is why it is to be protected from tools and to be made visible.</div><div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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></div></span><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></div></blockquote><div><br></div><div>Huh? This proposal is inspired by Python syntax; many other languages also have multiline string literals. ES6 in particular comes to mind. All of these do not strip trailing whitespace. Some tools may offer to strip that whitespace, but I don&#39;t doubt that there are many tools which leave multiline literals alone. What is so special about Swift that this is an issue here where it has not been elsewhere?</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><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></div><div>There is no way around it: tools expect trailing whitespace to be irrelevant.</div></div></div></blockquote><div><br></div><div>Again, this does not make sense. If trailing whitespace is _relevant_, then why would tools consider them irrelevant? why would users choose to use tools that delete things that they consider relevant instead of using or making tools that correctly consider them relevant? Also, if you believe them to be important, why would you support Swift prohibiting their literal use? why wouldn&#39;t you enthusiastically support arbitrary trailing whitespace and diligently file bugs against any tools that strip them out of literals?</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 class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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> <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>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><br></div><div>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></div></span><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><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>but trailing non-breaking spaces or trailing half-width spaces are not a problem.</div></div></div></div></div></blockquote><div><br></div></span><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></div></blockquote><div><br></div><div>And what would you propose to do about invisible zero-width glyphs in strings? There is no end to this. Unicode strings can have arbitrary amounts of invisible data. You cannot determine the content of a string by visual inspection. This is why I conclude that it should be an explicit non-goal to make non-printing characters visible.</div><div><br></div><div>Again, if this is a common issue, one would expect pervasive tooling to print invisible characters. Either there is such tooling, in which case the issue is adequately addressed, or there is no such tooling, which would be evidence to me that it is not a pervasive problem. I simply see no evidence, given the multitude of languages with similar features, that it is an issue that requires enforcement in the language rules.</div><div><br></div></div></div></div>