Disallowing many expressions with unused result (@error_unused_result?)

I recently criticized Swift 3 for allowing many expressions with no side effects as statements, in this blog post: Application Security & Software Security Blog | Synopsys (search for "that expression"). I've seen some related discussion such as "Make non-void functions @warn_unused_result by default", but not quite this.

For emphasis, let me include a real example (from open-source software, simplified) of defective JavaScript code that happens to be legal Swift as well:

var html = "<table class='modification'>" +
      "<tbody>" +
      trs
      "</tbody>" +
      "</table>";

DEFECT SPOILER: (There is a missing '+')

Part of my argument is that people commonly ignore compiler warnings. We see lots of defective code that would be (or is) caught by compiler warnings but people don't pay attention.

I have not formulated this into a detailed proposal, but I suspect that because of Swift's pervasive overloading, implicit constructor calls, etc., it would involve introducing a new @error_unused_result annotation and using that in many places in the standard library. I also suggest that user overloads of traditionally non-side-effecting operators, as well as non-mutating struct methods, be @error_unused_result by default, or perhaps by mandate. Our experience also suggests this @error_unused_result feature could also be useful for ordinary methods of classes, as we find a number of defects where a method call is expecting a side effect but there is none, because the method is only useful for its return value.

If you would like to see more defect examples from open-source software (other languages for the moment), I should be able to dig up some more.

Thanks

···

--
Peter Dillinger, Ph.D.
Software Engineering Manager, Coverity Analysis, Software Integrity Group | Synopsys

If I copy/paste your code (and add a definition for “trs”), Swift already gives a warning:
let trs = "trs"
var html = "<table class='modification'>" +
  "<tbody>" +
trs
"</tbody>" + // Warning: Result of operator '+' is unused
"</table>";

What version of Swift are you using? IIRC, it didn’t start doing that until Swift 3.

- Dave Sweeris

···

On Mar 24, 2017, at 3:57 PM, Peter Dillinger via swift-evolution <swift-evolution@swift.org> wrote:

I recently criticized Swift 3 for allowing many expressions with no side effects as statements, in this blog post: Application Security & Software Security Blog | Synopsys Blog (search for "that expression"). I've seen some related discussion such as "Make non-void functions @warn_unused_result by default", but not quite this.

For emphasis, let me include a real example (from open-source software, simplified) of defective JavaScript code that happens to be legal Swift as well:

var html = "<table class='modification'>" +
     "<tbody>" +
     trs
     "</tbody>" +
     "</table>";

DEFECT SPOILER: (There is a missing '+')

Part of my argument is that people commonly ignore compiler warnings. We see lots of defective code that would be (or is) caught by compiler warnings but people don't pay attention.

I have not formulated this into a detailed proposal, but I suspect that because of Swift's pervasive overloading, implicit constructor calls, etc., it would involve introducing a new @error_unused_result annotation and using that in many places in the standard library. I also suggest that user overloads of traditionally non-side-effecting operators, as well as non-mutating struct methods, be @error_unused_result by default, or perhaps by mandate. Our experience also suggests this @error_unused_result feature could also be useful for ordinary methods of classes, as we find a number of defects where a method call is expecting a side effect but there is none, because the method is only useful for its return value.

If you would like to see more defect examples from open-source software (other languages for the moment), I should be able to dig up some more.

If I copy/paste your code (and add a definition for “trs”), Swift already gives a warning: ... What version of Swift are you using?

The first word of my subject is “disallowing” not “warning.” And I wrote, and you quoted, the following about compiler warnings:

Part of my argument is that people commonly ignore compiler warnings. We see lots of defective
code that would be (or is) caught by compiler warnings but people don't pay attention.

I'm not sure what your point was, but I consider the fact that the compiler already has a proof-of-concept implementation of my proposal as a positive, risk- and expense-reducing aspect of the proposal.

···

--
Peter Dillinger, Ph.D.
Software Engineering Manager, Coverity Analysis, Software Integrity Group | Synopsys

In the Swift 3 timeframe, we adopted pretty much exactly these rules, albeit making value-producing operations *warn* by default instead of error. There's already a @discardableResult attribute that you can apply to declarations whose result is intended to be discardable. The philosophy of warnings vs errors is being discussed in your thread on unreachable code, so I don't think it needs to be reiterated here.

-Joe

···

On Mar 24, 2017, at 3:57 PM, Peter Dillinger via swift-evolution <swift-evolution@swift.org> wrote:

I recently criticized Swift 3 for allowing many expressions with no side effects as statements, in this blog post: Application Security & Software Security Blog | Synopsys Blog (search for "that expression"). I've seen some related discussion such as "Make non-void functions @warn_unused_result by default", but not quite this.

For emphasis, let me include a real example (from open-source software, simplified) of defective JavaScript code that happens to be legal Swift as well:

var html = "<table class='modification'>" +
     "<tbody>" +
     trs
     "</tbody>" +
     "</table>";

DEFECT SPOILER: (There is a missing '+')

Part of my argument is that people commonly ignore compiler warnings. We see lots of defective code that would be (or is) caught by compiler warnings but people don't pay attention.

I have not formulated this into a detailed proposal, but I suspect that because of Swift's pervasive overloading, implicit constructor calls, etc., it would involve introducing a new @error_unused_result annotation and using that in many places in the standard library. I also suggest that user overloads of traditionally non-side-effecting operators, as well as non-mutating struct methods, be @error_unused_result by default, or perhaps by mandate. Our experience also suggests this @error_unused_result feature could also be useful for ordinary methods of classes, as we find a number of defects where a method call is expecting a side effect but there is none, because the method is only useful for its return value.