> 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: > 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>" + > 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.
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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
