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

David Owens II david at owensd.io
Fri Mar 11 14:06:04 CST 2016

> 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 */ {


} 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()


// 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160311/ae2f95ef/attachment.html>

More information about the swift-evolution mailing list