<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=""><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 class=""><br class=""></div><div class="">Jordan</div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 20, 2015, at 11:55 , Jesse Rusak via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</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="">Hi all,<div class=""><br class=""></div><div class=""><div class="">Following a <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151214/000348.html" class="">discussion on swift-dev</a> about <a href="https://bugs.swift.org/browse/SR-186" class="">bug SR-186</a>, I would like to propose a rule about how Swift should handle comments next to operators in order to make it clear how to resolve some existing bugs & inconsistencies.</div><div class=""><br class=""></div><div class=""><div class="">Please take a look at the pseudo-proposal below. I believe it is in line with the current intention of the language reference, but I’m interested in hearing differing opinions. Also, most of the cases in which this comes up are pretty contrived, so I’d love to hear if anyone has any common/important cases where this makes a difference.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jesse</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">Background</b></div><div class=""><br class=""></div><div class="">At the moment, comments next to operators are generally treated as non-whitespace for the purpose of <a href="https://developer.apple.com/library/mac/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/doc/uid/TP40014097-CH30-ID418" class="">determining whether an operator is prefix/postfix/binary</a>, meaning that this fails to compile:</div><div class=""><br class=""></div><div class=""><font face="Andale Mono" class="">if /* comment */!foo { … }</font></div><div class=""><br class=""></div><div class="">Because the “!” is parsed as binary operator (no whitespace on either side), rather than as a prefix operator, which seems undesirable. This behavior is also not consistently applied. For example, this currently works:</div><div class=""><br class=""></div><div class=""><font face="Andale Mono" class="">1 +/* comment */2</font></div><div class=""><font face="Andale Mono" class=""><br class=""></font></div><div class="">(I believe this is unintentional; the "+/*" is treated as one token and sees the whitespace to its right.)</div><div class=""><br class=""></div><div class="">In order to resolve these issues, we need a general rule about how this is expected to behave.</div><div class=""><br class=""></div><div class=""><b class="">Proposed changes</b></div><div class=""><b class=""><br class=""></b></div><div class="">Comments should be treated as whitespace for all of the purposes in the “operators” section of the swift language reference: determining whether an operator is binary, prefix, or postfix, as well as the special rules around the “!” and “?” predefined operators.</div><div class=""><br class=""></div><div class=""><b class="">Impact on existing code</b></div><div class=""><b class=""><br class=""></b></div><div class="">Only code with comments immediately next to operators will be affected. This is not expected to be very common, and could be fixed by adding a space next to the operator in question or moving the comment outside of the expression. It would probably be possible to produce fix-its for these, though I’m not sure it’s worth it. Here are some examples of the changes.</div><div class=""><b class=""><br class=""></b></div><div class="">Some cases which were previously errors will now work:</div><div class=""><br class=""></div><div class=""><div class=""><font face="Andale Mono" class="">/* */!foo</font></div><div class=""></div><div class=""><font face="Andale Mono" class="">1/**/+ 2</font></div><div class=""><font face="Andale Mono" class="">1 /**/+ 2</font></div></div><div class=""><span style="font-family: 'Andale Mono';" class="">1 +/*hi*/2</span></div><div class=""><br class=""></div><div class="">Some cases which would previously work will now error (these are breaking changes):</div><div class=""><br class=""></div><div class=""><span style="font-family: 'Andale Mono';" class="">foo/* */?.description</span></div><div class=""><span style="font-family: 'Andale Mono';" class="">foo/* */!</span></div><div class=""><div class=""><span style="font-family: 'Andale Mono';" class="">1/**/+2</span></div><div class=""><div class=""></div></div></div><div class=""><div class=""><font face="Andale Mono" class="">1+/**/2</font></div></div><div class=""><font face="Andale Mono" class=""><br class=""></font></div><div class="">Examples of things which will continue to be errors:</div><div class=""><br class=""></div><div class=""><span style="font-family: 'Andale Mono';" class="">!/* */foo</span></div><div class=""><div class=""><span style="font-family: 'Andale Mono';" class="">1+/* */2</span></div></div><div class=""><span style="font-family: 'Andale Mono';" class=""><br class=""></span></div><div class="">And things which will continue to work:</div><div class=""><span style="font-family: 'Andale Mono';" class=""><br class=""></span></div><div class=""><div class=""><div class=""><span style="font-family: 'Andale Mono';" class="">foo!// this is dangerous</span></div><div class=""></div></div><div class=""><span style="font-family: 'Andale Mono';" class="">1 +/**/ 2</span></div><div class=""><span style="font-family: 'Andale Mono';" class="">1 +/* hi */2</span></div><div class=""><br class=""></div></div><div class=""><b class="">Alternatives considered</b></div><div class=""><b class=""><br class=""></b></div><div class="">We could instead specify that comments are treated as though they are not present. This more-closely matches some people’s mental model of comments. However, it is harder to describe (the characters are not removed entirely as they still separate tokens) and goes against the current general rule in the language reference that comments are whitespace.</div><div class=""><br class=""></div><div class="">This also has the disadvantage that you have to look at the other side of a comment to determine if an operator has whitespace around it. For example:</div><div class=""><b class=""><br class=""></b></div><div class=""><div class=""><font face="Andale Mono" class="">a = 1 +/* a very long </font><font face="Andale Mono" class="">comment </font><span style="font-family: 'Andale Mono';" class="">*/2</span></div><div class=""><br class=""></div><div class="">You can’t tell just by looking near the “+” whether it is a binary or prefix operator. </div></div></div><div class=""><br class=""></div><div class="">Another alternative is a more precise rule about how comments are handled everywhere in the language (e.g. there must be no effect when replacing a comment with a space character). This has the advantage of possibly resolving other ambiguities, but has potentially far-reaching consequences in various edge cases (for example, multi-line comments which span lines are currently treated as end-of-line). </div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=ZEz4qHYnXhPr3bBPu-2FxP4tN3HfWKL-2FtJpqkQ0gkOVSCSidqBhhzVsTnBWvcS3KMURvbL9gpX7y-2FbVZlJARpnJPFC5yfvjgHFZhhCTtU3OL9jg6yljdBe-2B8yG9TvwuVYWE-2BVpl0S-2FXaLbs8BgKfnq-2FEEo1EssBlY-2FnU2FpYE0dNTUP4UT3gf2wON6HixkijfzNnpAEf8yuhfolZJGwT4h1FUCm4I1wD-2BLM-2Fz-2BsneNgO8-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>