<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="">Any other comments about this? Can someone from the core team make a call on this, or should we ask for comments on swift-evolution?<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 15, 2015, at 7:15 PM, Jesse Rusak <<a href="mailto:me@jesserusak.com" class="">me@jesserusak.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class="">On Dec 14, 2015, at 9:42 PM, Chris Lattner via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div></blockquote></div></div></blockquote></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class=""><div class="">There are two defensible models here:</div><div class=""><br class=""></div><div class="">1) comments should be treated as whitespace.</div><div class="">2) comments should be treated as if they were not present.</div><div class=""><br class=""></div><div class="">The later model seems more ideal to me (because you can put whitespace on either side of the comment after all), but I don’t have a strong opinion about that. What do others think?</div></div></blockquote></div></div></blockquote></div></div></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><br class=""></blockquote><blockquote type="cite" class=""><div class="">On Dec 15, 2015, at 1:08 AM, John Calsbeek via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">If you treat comments as though they are not present, you can no longer reason locally about whitespace on either side of an operator. Straw example:</div><div class=""><br class=""></div><div class=""><div class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><font face="Andale Mono" class="">foo/* insert an</font></div><div class=""><font face="Andale Mono" class="">excerpt from War</font></div><div class=""><font face="Andale Mono" class="">and Peace here */!</font></div></div></div></div></div><div class=""><br class=""></div><div class="">I need to scan to the other side of the comment to determine if ! is preceded by whitespace.</div><div class=""><br class=""></div><div class="">There is already a list of situations in which some token is treated as whitespace for the purpose of operators in <i class="">The Swift Programming Language</i>:</div><div class=""><br class=""></div><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class=""><p class="para" style="border: 0px; margin: 0px 0px 15px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(65, 65, 65); line-height: 20.299999237060547px; font-family: Helvetica, Arial, sans-serif;">For the purposes of these rules, the characters <code class="code-voice" style="border: 0px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(128, 128, 128); font-family: Menlo, monospace; word-wrap: break-word;">(</code>, <code class="code-voice" style="border: 0px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(128, 128, 128); font-family: Menlo, monospace; word-wrap: break-word;">[</code>, and <code class="code-voice" style="border: 0px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(128, 128, 128); font-family: Menlo, monospace; word-wrap: break-word;">{</code> before an operator, the characters <code class="code-voice" style="border: 0px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(128, 128, 128); font-family: Menlo, monospace; word-wrap: break-word;">)</code>, <code class="code-voice" style="border: 0px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(128, 128, 128); font-family: Menlo, monospace; word-wrap: break-word;">]</code>, and <code class="code-voice" style="border: 0px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(128, 128, 128); font-family: Menlo, monospace; word-wrap: break-word;">}</code> after an operator, and the characters <code class="code-voice" style="border: 0px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(128, 128, 128); font-family: Menlo, monospace; word-wrap: break-word;">,</code>, <code class="code-voice" style="border: 0px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(128, 128, 128); font-family: Menlo, monospace; word-wrap: break-word;">;</code>, and <code class="code-voice" style="border: 0px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(128, 128, 128); font-family: Menlo, monospace; word-wrap: break-word;">:</code> are also considered whitespace.</p></div><div class=""><p class="para" style="border: 0px; margin: 0px 0px 15px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(65, 65, 65); line-height: 20.299999237060547px; font-family: Helvetica, Arial, sans-serif;">There is one caveat to the rules above. If the <code class="code-voice" style="border: 0px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(128, 128, 128); font-family: Menlo, monospace; word-wrap: break-word;">!</code> or <code class="code-voice" style="border: 0px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(128, 128, 128); font-family: Menlo, monospace; word-wrap: break-word;">?</code> predefined operator has no whitespace on the left, it is treated as a postfix operator, regardless of whether it has whitespace on the right. To use the <code class="code-voice" style="border: 0px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(128, 128, 128); font-family: Menlo, monospace; word-wrap: break-word;">?</code> as the optional-chaining operator, it must not have whitespace on the left. To use it in the ternary conditional (<code class="code-voice" style="border: 0px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(128, 128, 128); font-family: Menlo, monospace; word-wrap: break-word;">?</code> <code class="code-voice" style="border: 0px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(128, 128, 128); font-family: Menlo, monospace; word-wrap: break-word;">:</code>) operator, it must have whitespace around both sides.</p></div></blockquote><div class="">Given that, it seems more natural to me to define comments as “treated-as-whitespace” in the same way.</div><div class=""><br class=""></div><div class="">“Treated as not present” is also not quite the right way to word the opposite case, since comments would still separate tokens. Say you had an automated tool that deletes comments (perhaps unlikely, but let’s roll with it). “Treated as not present” says you should completely delete the comment, but that doesn’t actually work since it could still cause two separate tokens to be glued together. “Treated as whitespace” just means that you have to replace the comment with at least one character of whitespace.</div></div></div></blockquote><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">FWIW, I agree with John about this. I think either model is reasonable but treating comments as whitespace is better because:</div><div class=""><br class=""></div><div class="">* The Swift language reference already states the general rule that comments are whitespace; I think it’s better to apply this throughout than change it.</div><div class=""><br class=""></div><div class="">* I think it’s easier to explain that "comments are whitespace" than "comments are treated as not present except they separate tokens”.</div><div class=""><div class=""><br class=""></div><div class="">* The non-local effects John describes are mildly awkward for human readers and in the lexer. (I think we’d have to walk backwards through slash-star comments to determine if we have space to the left of an operator.)</div><div class=""><br class=""></div></div><div class="">- Jesse</div></div></div></blockquote></div><br class=""></div></body></html>