>> On Dec 14, 2015, at 9:42 PM, Chris Lattner via swift-dev
>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>> There are two defensible models here:
>>
>> 1) comments should be treated as whitespace.
>> 2) comments should be treated as if they were not present.
>>
>> 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?
>
> On Dec 15, 2015, at 1:08 AM, John Calsbeek via swift-dev
> <swift-dev@swift.org> wrote:
>
> 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:
>
> foo/* insert an
> excerpt from War
> and Peace here */!
>
> I need to scan to the other side of the comment to determine if ! is preceded
> by whitespace.
>
> There is already a list of situations in which some token is treated as
> whitespace for the purpose of operators in The Swift Programming Language:
>
> For the purposes of these rules, the characters (, [, and { before an
> operator, the characters ), ], and } after an operator, and the characters ,,
> ;, and : are also considered whitespace.
>
> There is one caveat to the rules above. If the ! or ? 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 ? as the optional-chaining
> operator, it must not have whitespace on the left. To use it in the ternary
> conditional (? :) operator, it must have whitespace around both sides.
>
> Given that, it seems more natural to me to define comments as
> “treated-as-whitespace” in the same way.
>
> “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.
FWIW, I agree with John about this. I think either model is reasonable but
treating comments as whitespace is better because:
* 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.
* I think it’s easier to explain that "comments are whitespace" than "comments
are treated as not present except they separate tokens”.
* 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.)
- Jesse
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
