> Am 22.04.2017 um 21:27 schrieb Xiaodi Wu <[email protected]>: > > On Sat, Apr 22, 2017 at 12:57 PM, Thorsten Seitz <[email protected] > <mailto:[email protected]>> wrote: > >> Am 22.04.2017 um 17:08 schrieb Xiaodi Wu <[email protected] >> <mailto:[email protected]>>: >> >> On Sat, Apr 22, 2017 at 3:21 AM, Thorsten Seitz <[email protected] >> <mailto:[email protected]>> wrote: >> >>> Am 21.04.2017 um 20:48 schrieb Xiaodi Wu via swift-evolution >>> <[email protected] <mailto:[email protected]>>: >>> >>> On Fri, Apr 21, 2017 at 1:45 PM, Erica Sadun <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> On Apr 21, 2017, at 12:40 PM, Xiaodi Wu via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> On Fri, Apr 21, 2017 at 8:48 AM, Robert Bennett via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> 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. >>>> >>>> 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? >>> >>> 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. >>> >>> 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? >> >> I think „single-line“ and „multiline“ should foremost apply to the code >> representation of a string and not its result. >> Otherwise "foo\nbar“ would be a multiline string with your reasoning, >> wouldn’t you agree? >> >> 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. > > I know that we are talking about string literals, not strings, that’s why I > talked about _representations_ vs. _results_. > > 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. > 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“). > > 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). > > 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_. > > 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. > The result would be > (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 > (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`). > > It _is_ currently possible for a multiline string literal to represent a > single-line string: > > ''' > 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. > '‘'
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. > > 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 `\`. > This is similar to the normalization of the literal newline to `\n`. > > 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! > 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. > > This argument is problematic. Is your position that literal trailing > whitespace in a multiline string literal is *relevant* or *non-relevant*? Relevant, of course. That is why it is to be protected from tools and to be made visible. > > 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. 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. 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 :-) There is no way around it: tools expect trailing whitespace to be irrelevant. > 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. > > 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_. > > 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, 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. > but trailing non-breaking spaces or trailing half-width spaces are not a > problem. 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. -Thorsten > > -Thorsten > >> >> Therefore a multiline string is one which is written over several lines of >> *code* to make maintenance easier. >> From that follows naturally that as soon as line breaks are introduced for >> hard wrapping we are talking about multiline strings. >> >> 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. >> >> -Thorsten >> >> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
