<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 22, 2015, at 1:39 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 21, 2015, at 19:23, Jesse Rusak <<a href="mailto:me@jesserusak.com" class="">me@jesserusak.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 21, 2015, at 3:18 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">After looking at all your examples, I think I prefer "comments are not there" with a possible "multi-line comments are treated like newlines" extension. But either way I think having an actual model here and sticking to it is an improvement!</div></div></div></blockquote><div class=""><br class=""></div><div class=""><div class="">Thanks for your thoughts! To be clear, are you suggesting “comments are not there” for the purposes of whitespace near operators, or as part of a more-general rule to be applied everywhere? (i.e. do you mean the first or second of the alternatives I listed?)</div></div></div></div></div></blockquote><br class=""></div><div class="">I'm not sure how your two alternatives map to these options, but I think the model I like has</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">foo/*abc*/!</div></blockquote><br class=""><div class="">as a postfix '!'. I'm not sure if I want to count</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">foo/*abc</div><div class="">*/+ bar</div></blockquote><br class=""><div class="">as an infix '+', as an error, or as a de-facto line continuation mechanism (making a postfix '+'). I do agree it's important to pick something.</div></div></div></blockquote><br class=""></div><div>I’ve spent some more time thinking about this. I think that “comments are whitespace” is a simpler model, but I do think it’s more surprising for many people, and (as Chris pointed out earlier) is less flexible, since you can always add whitespace next to a comment if you want it. So, I think I’m coming around to the “comments are not there” behavior. </div><div><br class=""></div><div>For your latter example, my feeling is that having the *content* of a comment affect the parsing of the surrounding code (i.e. treating your last example as an error or infix +) is surprising. For example, it would surprise me that this works:</div><div><br class=""></div><div>a+/* something */b</div><div><br class=""></div><div>but this doesn’t:</div><br class=""><div class=""><div>a+/* something </div><div> something */b</div></div><div><br class=""></div><div>So, I think I’ll write up a draft proposal with the “comments are not there” behavior and see how it looks.</div><div><br class=""></div><div>- Jesse</div></body></html>