[Review] SE-0037 Clarify interaction between comments & operators

Hello Swift community,

The review of “Clarify interaction between comments & operators” begins now and runs through March 15, 2016. The proposal is available here:

  swift-evolution/0037-clarify-comments-and-operators.md at master · apple/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:
  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at:

Thank you,

-Chris
Review Manager

I’m sorta in favor… Reading the proposal, I agree that something needed to be done, but I think a better solution would’ve been to disallow comments between operators and their operands. Sorry, I didn’t see the thread about it, or I would’ve said something there.

Anyway, if it’s this vs leaving it alone, then +1 for this.

-Dave Sweeris

···

On Mar 11, 2016, at 12:00 PM, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of “Clarify interaction between comments & operators” begins now and runs through March 15, 2016. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0037-clarify-comments-and-operators.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:
  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at:

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris
Review Manager
_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

  • What is your evaluation of the proposal?

I’m in favour of it; comments shouldn’t conflict with parsing of operators, no matter where someone decides to put them. My preference is towards the “treat comments as absent” alternative however; while I do agree in principle that comments should be placed stupidly, I’m not sure that that’s something we should try to control here. That said, if use of whitespace as proposed would be easier for the compiler either in speed or complexity, then I’m fine with it as a solution too.

  • Is the problem being addressed significant enough to warrant a change to Swift?

I’d say so; comments shouldn’t be allowed to affect the compiler IMO, yet currently they can.

  • Does this proposal fit well with the feel and direction of Swift?

Yes.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read of the proposal, considered the alternatives.

Also I’m a -1 to suggestions that /* … */ style comments should be removed; I use these almost exclusively as I can never be 100% sure that a comment won’t need to spill onto more lines, and I hate how multi-line // comments look. I use // for end of line comments though, or for adding // MARK: tags to code sections.

  • What is your evaluation of the proposal?

I think the alternative to simply ignore comments would be a better direction, especially since the proposal breaks code.

  • Is the problem being addressed significant enough to warrant a change to Swift?

No.

  • Does this proposal fit well with the feel and direction of Swift?

No.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Other languages ignore comments, and hence I think the alternative discussed in the proposal represents a better direction.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read.

···

+1 for the chosen path of the proposal.

However, one alternative is to remove /* ... */ style comments all together. Every example in the proposal are examples of commenting style that really have no business in the code.

-David

···

On Mar 11, 2016, at 10:12 AM, Dave via swift-evolution <swift-evolution@swift.org> wrote:

I’m sorta in favor… Reading the proposal, I agree that something needed to be done, but I think a better solution would’ve been to disallow comments between operators and their operands. Sorry, I didn’t see the thread about it, or I would’ve said something there.

Anyway, if it’s this vs leaving it alone, then +1 for this.

-Dave Sweeris

On Mar 11, 2016, at 12:00 PM, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of “Clarify interaction between comments & operators” begins now and runs through March 15, 2016. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0037-clarify-comments-and-operators.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:
  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at:

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris
Review Manager
_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I can't agree that /*…*/ comments are useless. The examples in the proposal aren't things I would write, but I can certainly think of other places I use them.

if foo > 0 {
} else if foo < 0 {
} else /* foo == 0 */ {
}

// We can't use SpecificType here because of XXX.
let foo: protocol<OtherType/*, SpecificType*/> = bar()

…and then given that we have /**/ comments in the language, we should define their behavior even in places you and I personally don't intend to write them.

Jordan

···

On Mar 11, 2016, at 10:32 , David Owens II via swift-evolution <swift-evolution@swift.org> wrote:

+1 for the chosen path of the proposal.

However, one alternative is to remove /* ... */ style comments all together. Every example in the proposal are examples of commenting style that really have no business in the code.

-David

On Mar 11, 2016, at 10:12 AM, Dave via swift-evolution <swift-evolution@swift.org> wrote:

I’m sorta in favor… Reading the proposal, I agree that something needed to be done, but I think a better solution would’ve been to disallow comments between operators and their operands. Sorry, I didn’t see the thread about it, or I would’ve said something there.

Anyway, if it’s this vs leaving it alone, then +1 for this.

-Dave Sweeris

On Mar 11, 2016, at 12:00 PM, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of “Clarify interaction between comments & operators” begins now and runs through March 15, 2016. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0037-clarify-comments-and-operators.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:
  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at:

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris
Review Manager
_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I can't agree that /*…*/ comments are useless.

I didn't say they are useless, but they are the source of many troubles. Sure, they do bring their own value to the table as well.

The examples in the proposal aren't things I would write, but I can certainly think of other places I use them.

I argue that your examples are comments I'd red-flag and could be trivially written in a way with single-line comments.

} else /* foo == 0 */ {

vs.

} else { // foo == 0

The `// foo == 0` comment is what I'd call a "bad comment" though. It is a comment that cannot be trusted as it cannot be verified by the compiler and has great potential for being misleading. Depending on the size of the blocks of the code in the condition statements, it's also fairly obvious.

// We can't use SpecificType here because of XXX.
let foo: protocol<OtherType/*, SpecificType*/> = bar()

vs.

// We can't use SpecificType here because of XXX.
// Ideally: <OtherType, SpecificType>
let foo: protocol<OtherType> = bar()

I'd argue that both of these changes also make the code clearer as annotation data is not intermingled with what will actually be the code that will execute. In other words, as a code author, I don't need to parse out the comment block in my head to see what the code is really saying.

…and then given that we have /**/ comments in the language, we should define their behavior even in places you and I personally don't intend to write them.

Sure. I agreed +1 to the proposal as stated. However, I think there are other alternatives that weren't discussed in the thread or in the proposal.

-David

Yeah, I use them for stuff like that a lot, or if my comments are more, um, “paragraphical" in nature (I can be somewhat long-winded at times).

···

On Mar 11, 2016, at 1:29 PM, Jordan Rose <jordan_rose@apple.com> wrote:

I can't agree that /*…*/ comments are useless. The examples in the proposal aren't things I would write, but I can certainly think of other places I use them.

if foo > 0 {
} else if foo < 0 {
} else /* foo == 0 */ {
}

// We can't use SpecificType here because of XXX.
let foo: protocol<OtherType/*, SpecificType*/> = bar()

…and then given that we have /**/ comments in the language, we should define their behavior even in places you and I personally don't intend to write them.

Jordan

- Dave Sweeris

I’m sorta in favor… Reading the proposal, I agree that something needed to be done, but I think a better solution would’ve been to disallow comments between operators and their operands. Sorry, I didn’t see the thread about it, or I would’ve said something there.

I think there are cases where comments between operators & operands can be useful in long expressions. Arguably there are nicer ways to write this, but this pattern is pretty common in mathy code:

let total = (a + // base amount
             b / 2 + // half of leftovers from last time
             c + 1) // fudge factor

···

On Mar 11, 2016, at 1:12 PM, Dave via swift-evolution <swift-evolution@swift.org> wrote:

Anyway, if it’s this vs leaving it alone, then +1 for this.

-Dave Sweeris

On Mar 11, 2016, at 12:00 PM, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of “Clarify interaction between comments & operators” begins now and runs through March 15, 2016. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0037-clarify-comments-and-operators.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:
  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at:

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris
Review Manager
_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Hey Patrick,

Thanks for the feedback. A couple comments below:

  • What is your evaluation of the proposal?

I think the alternative to simply ignore comments would be a better direction, especially since the proposal breaks code.

Unfortunately, the alternative proposal (ignoring comments) could also break code because comments are currently treated as non-whitespace in most cases. For example, this currently works:

1 /* */+2

(Because the “+” has no whitespace on either side.) If comments were completely ignored, this would be an error since there is whitespace to the left of the “+” but not the right.

If you’re interested in a more complete discussion of this direction, you can see an earlier draft which proposed this in the history <https://github.com/apple/swift-evolution/blob/c719adf87dae3382319e387fcf3145322a9f1239/proposals/0037-clarify-comments-and-operators.md&gt;\.

  • Is the problem being addressed significant enough to warrant a change to Swift?

No.

This is admittedly a small issue, so I can understand this point of view. The current state, though, seems pretty surprising to me — comments are treated as non-whitespace in most cases, ignored in others, and the contents of comments can affect the interpretation of the surrounding code. These are pretty clearly bugs which, to me at least, seem worth fixing.

···

On Mar 12, 2016, at 2:16 PM, Patrick Gili via swift-evolution <swift-evolution@swift.org> wrote:

  • Does this proposal fit well with the feel and direction of Swift?

No.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Other languages ignore comments, and hence I think the alternative discussed in the proposal represents a better direction.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

That’s a good point. I was only thinking of the “/*…*/“ style. The inherent line breaks in the “//“ style make things much clearer.

- Dave Sweeris

···

On Mar 11, 2016, at 1:41 PM, Jesse Rusak <me@jesserusak.com> wrote:

On Mar 11, 2016, at 1:12 PM, Dave via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I’m sorta in favor… Reading the proposal, I agree that something needed to be done, but I think a better solution would’ve been to disallow comments between operators and their operands. Sorry, I didn’t see the thread about it, or I would’ve said something there.

I think there are cases where comments between operators & operands can be useful in long expressions. Arguably there are nicer ways to write this, but this pattern is pretty common in mathy code:

let total = (a + // base amount
             b / 2 + // half of leftovers from last time
             c + 1) // fudge factor

Anyway, if it’s this vs leaving it alone, then +1 for this.

-Dave Sweeris

On Mar 11, 2016, at 12:00 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

Hello Swift community,

The review of “Clarify interaction between comments & operators” begins now and runs through March 15, 2016. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0037-clarify-comments-and-operators.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:
  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at:

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris
Review Manager
_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution