> On Dec 28, 2015, at 11:49 AM, Jesse Rusak <[email protected]> wrote:
>
>>
>> On Dec 22, 2015, at 1:39 PM, Jordan Rose <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>> On Dec 21, 2015, at 19:23, Jesse Rusak <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>
>>>> On Dec 21, 2015, at 3:18 PM, Jordan Rose <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> 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!
>>>
>>> Thanks for your thoughts! To be clear, are you suggesting “comments are not
>>> there” for the purposes of whitespace near operators, or as part of a
>>> more-general rule to be applied everywhere? (i.e. do you mean the first or
>>> second of the alternatives I listed?)
>>
>> I'm not sure how your two alternatives map to these options, but I think the
>> model I like has
>>
>> foo/*abc*/!
>>
>> as a postfix '!'. I'm not sure if I want to count
>>
>> foo/*abc
>> */+ bar
>>
>> as an infix '+', as an error, or as a de-facto line continuation mechanism
>> (making a postfix '+'). I do agree it's important to pick something.
>
> I’ve spent some more time thinking about this. I think that “comments are
> whitespace” is a simpler model, but I do think it’s more surprising for many
> people, and (as Chris pointed out earlier) is less flexible, since you can
> always add whitespace next to a comment if you want it. So, I think I’m
> coming around to the “comments are not there” behavior.
>
> For your latter example, my feeling is that having the *content* of a comment
> affect the parsing of the surrounding code (i.e. treating your last example
> as an error or infix +) is surprising. For example, it would surprise me that
> this works:
>
> a+/* something */b
>
> but this doesn’t:
>
> a+/* something
> something */b
>
> So, I think I’ll write up a draft proposal with the “comments are not there”
> behavior and see how it looks.
And here’s the draft proposal:
https://github.com/jder/swift-evolution/blob/comments-and-operators/proposals/0000-clarify-comments-and-operators.md
- Jesse
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
