[swift-evolution] Disallowing many expressions with unused result (@error_unused_result?)

Peter Dillinger Peter.Dillinger at synopsys.com
Fri Mar 24 17:57:10 CDT 2017

I recently criticized Swift 3 for allowing many expressions with no side effects as statements, in this blog post: https://blogs.synopsys.com/software-integrity/2017/03/24/swift-programming-language-design-part-2/ (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>" +
      "</tbody>" +

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.


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

More information about the swift-evolution mailing list