<div dir="ltr"><div dir="ltr"><div dir="ltr">On Thu, Apr 25, 2019 at 5:42 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">So what you’re saying is: with CDI, the opt out is: bring the closing delimiter to the left margin, done.</div></blockquote><div><br></div><div>derp, thanks for completing my thought. Basically: some say "opt out" while I say "I choose to locate the left edge of my rectangle at the left edge of the actual source file". "Done" indeed.</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 26, 2019 at 6:25 AM Jim Laskey <<a href="mailto:james.laskey@oracle.com">james.laskey@oracle.com</a>> wrote:<br></div><div dir="ltr" class="gmail_attr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">The example that Kevin left to the imagination was;<div><br><span class="gmail-m_-1356879961163207762Apple-tab-span" style="white-space:pre-wrap">           </span>String s = """<br>    <span class="gmail-m_-1356879961163207762Apple-tab-span" style="white-space:pre-wrap">                             </span>some<br>    <span class="gmail-m_-1356879961163207762Apple-tab-span" style="white-space:pre-wrap">                       </span>        lines go here<br>""";</div><div><br></div><div>Which, while awkward, remains a natural progression of CDI, can be interpreted as heredoc, and no other indicator required.</div></div></blockquote><div><br></div><div>I persistently forget that people will sometimes want to do that, to keep their content within their customary source file column limit. (I want to downplay the notion of pasteability because that's precisely a feature of raw strings, which this is not.)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>Other notion mentioned;<br></div><div><br></div><div><span class="gmail-m_-1356879961163207762Apple-tab-span" style="white-space:pre-wrap">   </span>- \<Line Terminator> eats the terminator and continues on the next line.</div></div></blockquote><div><br></div><div>Eats the terminator plus all leading whitespace of the next line, yes?  I had forgotten that the reintroduction of escapes opened up this possibility, and I think it's pretty great -- quite a substantial fraction (25%+ I think) of all our multiline use cases that we've found are things like long exception messages where they don't actually want the newlines, they just want to be free of dealing with the damn quote-plus-quote.</div><div><br></div><div>Oh, and quite a few of <i>those</i> use cases are in annotations like <font face="monospace, monospace">@FlagSpec({"--foo", "long help text about --foo"})</font>, and I'm very happy that these are no longer excluded from indentation stripping.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><span class="gmail-m_-1356879961163207762Apple-tab-span" style="white-space:pre-wrap">          </span>- I suppose we could have \<Space> to mean continue here</div><div><span class="gmail-m_-1356879961163207762Apple-tab-span" style="white-space:pre-wrap">                      </span>- This could effective provide margin control</div></div></blockquote><div><br></div><div>I have to catch up on this thread to figure out what this means.</div><div><br></div><div>I also need to catch up on the issue of what to do with the trailing newline. We can get data on how often our string literals seem to want interior newlines but no trailing one. It would be a bit surprising if the trailing newline is automatically chomped, but at least you have two very simple and obvious ways to restore it (add another line or add `\n`), whereas chomping via library is sad for several reasons (including excluding those @FlagSpecs I mentioned above).</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div><blockquote type="cite"><div><div style="overflow-wrap: break-word;"><div><div><blockquote type="cite"><div>On Apr 25, 2019, at 8:19 PM, Kevin Bourrillion <<a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a>> wrote:</div><br class="gmail-m_-1356879961163207762Apple-interchange-newline"><div><div dir="ltr"><div>I'm sure I'm not saying anything totally new in the following, but this is my summary of why I don't see the necessity of any explicit opt-out like <font face="monospace, monospace">\-</font>.<br></div><div><br></div><div>Suppose I write this:<br><div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><font face="monospace, monospace">String s = </font><span style="font-family:monospace,monospace">"""</span></div></div></div><div><div><font face="monospace, monospace">    some</font></div></div><div><div><font face="monospace, monospace">    lines go here</font></div></div><div><div><font face="monospace, monospace">    """;</font></div></div></blockquote><div><div><br></div><div>And suppose I have learned to picture a rectangle whose left edge is the left edge of the ending delimiter.</div><div><br></div><div>Well, once I'm already picturing that rectangle based on the delimiter, then clearly if I leave the delimiter alone, that leaves the rectangle alone. I can change to</div><div><br></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><div><div><font face="monospace, monospace">String s = </font><span style="font-family:monospace,monospace">"""</span></div></div></div></div></div><div><div><div><div><font face="monospace, monospace">      some</font></div></div></div></div><div><div><div><div><font face="monospace, monospace">    lines go here</font></div></div></div></div><div><div><div><div><font face="monospace, monospace">    """;</font></div></div></div></div></blockquote><div><div><br></div><div>... to insert two spaces before `some`, and I can further change to</div><div><br></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><div><div><div><font face="monospace, monospace">String s = </font><span style="font-family:monospace,monospace">"""</span></div></div></div></div></div></div><div><div><div><div><div><font face="monospace, monospace">      some</font></div></div></div></div></div><div><div><div><div><div><font face="monospace, monospace">      lines go here</font></div></div></div></div></div><div><div><div><div><div><font face="monospace, monospace">    """;</font></div></div></div></div></div></blockquote><div><div><div><br></div>... to also insert two spaces before `lines`.</div><div><br></div><div>What is notable to me is that at no point did I ever change from <i>one kind</i> of string literal to <i>another</i>. There is no feature that I opted in or out of -- because there just doesn't need to be. That to me is a clear and compelling win for simplicity.</div><div><br></div><div>It's entirely possible this was all 100% clear already, in which case sorry!</div><div><br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 25, 2019 at 4:30 PM Liam Miller-Cushon <<a href="mailto:cushon@google.com" target="_blank">cushon@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Apr 25, 2019 at 8:56 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>> wrote:<br>
<br>
> For 2/3, here’s a radical suggestion.  Our theory is, a “fat” string is<br>
> one that is is co-mingled with the indentation of the surrounding code, and<br>
> one which we usually wish the compiler to disentangle for us.  By this<br>
> interpretation, fat single-line strings make no sense, so let’s ban them,<br>
> and similarly, text on the first line similarly makes little sense, so<br>
> let’s ban that too.  In other words, fat strings (with the possible<br>
> exception of the trailing delimiter) must exist within a “Kevin<br>
> Rectangle.”<br>
><br>
<br>
+1<br>
<br>
I thought Jim presented a good case for an exception for the trailing<br>
delimiter, but otherwise disallowing single-line 'fat' strings (single-line<br>
multi-line strings?) seems to mostly have upside.<br>
<br>
For 4 (opt out), I think it is OK to allow a self-stripping escape on the<br>
> first line (e.g., \-), which expands to nothing, but suppresses stripping.<br>
> This effectively becomes a “here doc”.<br>
><br>
<br>
This seems OK to me too, but is there good return on complexity? Closing<br>
delimiter influence can also be used to opt out of stripping. Are there<br>
enough use-cases to justify a second opt-out mechanism? And does it have to<br>
be decided now, or could it be added later?<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_-1356879961163207762gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span></div></div></div></div></div></div></div>
</div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span></div></div></div></div></div></div></div></div>