<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On Sep 30, 2019, at 6:37 PM, Brian Goetz <<a href="mailto:brian.goetz@oracle.com" class="">brian.goetz@oracle.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">This seems to cross the line between “new escape sequence” and “bespoke string literal language..."</span></div></blockquote></div><br class=""><div class="">Nope, I disagree.  It just applies the current concept “ancillary trailing space” (which did</div><div class="">not cross that line) to the spaces before \ at the end of the line.</div><div class=""><br class=""></div><div class="">When you think about the detailed mechanics of ancillary spaces before \LT, you surely note</div><div class="">that some tricky processing is going on, since they are stripped via a different rule than</div><div class="">ancillary spaces before LT.  Maybe that makes the feature feel weighty to you.  But users</div><div class="">won’t care a bit.  They will just know that unescaped spaces at the end of the line are ancillary</div><div class="">whether or not \ is present between them and the LT.  That makes the overall user model</div><div class="">simpler, not more complex.</div><div class=""><br class=""></div></body></html>