> On Dec 22, 2015, at 1:39 PM, Jordan Rose <[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.

- Jesse
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to