<div dir="ltr">On Fri, Apr 21, 2017 at 2:42 PM, Robert Bennett <span dir="ltr"><<a href="mailto:rltbennett@icloud.com" target="_blank">rltbennett@icloud.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"><div></div><div>It looks like we have different interpretations about what "literal" means (I think this may have been brought up in earlier messages in this thread; I don't remember the resolution). I interpreted it as meaning the same thing as literal in *LiteralConvertible, i.e., a Swift type that is written out in source. Multiline string literal would then refer to a multiline "piece of source code representing a String". It sounds like you are taking "literal" to mean something that *literally* (to the extent possible) represents its data, which in the case of String would mean writing out the source code exactly as the resulting String will appear. Up until now I think those two interpretations of "literal" were equivalent. For no type other than String is the physical layout in source related to the underlying data, and prior to this proposal the point was moot for String because there was only a single allowable layout (barring concatenation with +, which utilizes multiple independent literals).</div><div><br></div><div>So, my view of the goal of this proposal is to allow writing a StringLiteralType across multiple lines. It appears your view is to allow using multiple lines to *literally* represent a String's content.</div></div></blockquote><div><br></div><div>Yes, indeed, a very good summary. I think, if I read between the lines correctly, the core team is intentionally making sure that these two views of a literal will remain equivalent, based on which subset of the current proposal has been accepted and which has been stricken. I'm arguing here that we should continue down that road.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Again, for editors that indent wrapped lines, disallowing manually breaking lines will actually introduce ambiguity into the multiline string, which runs counter to the goal of the proposal. Also, from an ideological standpoint I see no reason to disallow this feature.</div></div></blockquote><div><br></div><div>I'm not supremely opposed to it either. The point of this exercise is to tease out what exactly is accomplished by adding it and whether it's worth the implementation effort and additional complexity in features. Surely, there is more to be said for it than merely accommodating people who don't like the look of soft-wrapped text.</div><div><br></div><div>The other point of the exercise is to discuss how it impacts our conceptions of what a literal is and what it ought to be.</div><div><br></div><div>On additional aim here is to drive home the point that escaping line breaks is not an issue inherent to _multiline_ strings, but even single-line strings might need to be broken up into multiple lines of source code. So, if we agree that escaping newlines is a feature that we want to have, a design that addresses """this""" but not "this" is incomplete and needlessly restrictive.</div><div><br></div><div>One final aim is to argue that whether or not this feature is added, it is an orthogonal question to that of trailing whitespace at the end of lines in a multiline literal. For the moment, that is the most salient part of the conversation, given the thread that we're in.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class="HOEnZb"><font color="#888888"><div>-- Robert</div></font></span><div><div class="h5"><div><br>On Apr 21, 2017, at 2:48 PM, 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 1:45 PM, Erica Sadun <span dir="ltr"><<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.com</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"><div style="word-wrap:break-word"><span class="m_-5610570443228940168gmail-"><br><div><blockquote type="cite"><div>On Apr 21, 2017, at 12:40 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-5610570443228940168gmail-m_482158630296011926Apple-interchange-newline"><div><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></div></div></div></blockquote><br></div></span><div>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><br></div><div>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></div></div></blockquote></div><br></div></div>