Hi all, Following a discussion on swift-dev <https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151214/000348.html> about bug SR-186 <https://bugs.swift.org/browse/SR-186>, 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.
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. Thanks, Jesse Background At the moment, comments next to operators are generally treated as non-whitespace for the purpose of determining whether an operator is prefix/postfix/binary <https://developer.apple.com/library/mac/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/doc/uid/TP40014097-CH30-ID418>, meaning that this fails to compile: if /* comment */!foo { … } 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: 1 +/* comment */2 (I believe this is unintentional; the "+/*" is treated as one token and sees the whitespace to its right.) In order to resolve these issues, we need a general rule about how this is expected to behave. Proposed changes 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. Impact on existing code 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. Some cases which were previously errors will now work: /* */!foo 1/**/+ 2 1 /**/+ 2 1 +/*hi*/2 Some cases which would previously work will now error (these are breaking changes): foo/* */?.description foo/* */! 1/**/+2 1+/**/2 Examples of things which will continue to be errors: !/* */foo 1+/* */2 And things which will continue to work: foo!// this is dangerous 1 +/**/ 2 1 +/* hi */2 Alternatives considered 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. 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: a = 1 +/* a very long comment */2 You can’t tell just by looking near the “+” whether it is a binary or prefix operator. 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).
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
