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!
Jordan > On Dec 20, 2015, at 11:55 , Jesse Rusak via swift-evolution > <[email protected]> wrote: > > 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
