<div dir="ltr">On Fri, Apr 21, 2017 at 8:48 AM, Robert Bennett via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></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">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></blockquote><div><br></div><div>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><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">
Even if we intended to print every string we used, I don't agree that a string's representation in code should be coupled to its appearance when printed. That seems like a needless restriction to impose on the language.</blockquote><div><br></div><div>I disagree that it is needless. To me, it is a sine qua non and raison d'être of literals. It is, after all, what the word "literal" means.</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">The whole point of multiline strings is to be able to visually lay out strings as desired, independent of the editor.</blockquote><div><br></div><div>I don't believe that's correct. The whole point of multiline strings it to be able to use literal newlines, no more and no less. I disagree strongly with the idea that a literal should support "laying out strings as desired"--only representing strings literally.</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">Allowing manual line breaks without introducing a newline is one more step toward completing this goal.<br>
<br>
To respond to your specific question as to why soft wrap is insufficient: it either looks bad because the wrapped text is unindented, or it introduces ambiguity by indenting the wrapped text (is that a wrapped line or two separate lines?). As Adrian Zubarev pointed out, we wouldn't need multiline string literals at all if we were content with manually inserting "\n" in multline strings and living with the soft wrapping.</blockquote><div><br></div><div>Again, I understand the whole point of multiline string literals to be allowing the use of literal newlines. The part about not liking soft-wrapping, afaict, was never discussed during review as a motivation. I personally do not use soft wrapping, but I have no problem with other people using it. Besides that, there's the option of not wrapping (my personal choice) and the option of hard wrapping using concatenation.</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">Evidently we are not content with that, so neither should we be content with having no way to break up long lines containing no newline character.<br>
<br>
Finally, I see no reason why we should be fighting against this. It only makes multiline strings more capable. If you don't want to use manual wrapping of lines, you don't have to.<br></blockquote><div><br></div><div>This, IMO, is the wrong kind of reasoning. All additive features can be summed up as "you don't have to use it if you don't like it." But that is not the bar for including a feature. Each addition makes the language more difficult to master and has the potential to make the resulting code more difficult to read and understand. On balance, would this particular feature hold its own weight? I don't think that avoiding the "it looks bad" issue with soft-wrapping warrants such an addition.</div><div><br></div></div></div></div>