[swift-evolution] Make non-void functions @warn_unused_result by default

Chris Lattner clattner at apple.com
Wed Mar 2 11:12:10 CST 2016


> On Mar 2, 2016, at 7:51 AM, Gwendal Roué via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> Le 2 mars 2016 à 16:21, Step C via swift-evolution <swift-evolution at swift.org> a écrit :
>> 
>>> On Mar 2, 2016, at 3:24 AM, Austin Zheng via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> Agreed. I think encouraging the "_ = returnValueIgnored()" pattern is a good way to have code disambiguate between "I don't care about the return value" and "I forgot to use it/called the wrong API method by accident". I've seen this issue in production code a couple of times.
>> 
>> I have also used and seen this pattern a bunch ("_ = ...").  It communicates powerfully to later code readers with the intention is in the code.
> 
> Hello, we need more balance here.
> 
> `_ = …` does not communicate anything. It could be a latent bug because some corner case has been ignored, just as well as the intentional discarding of an unused value.

I disagree.

The difference between:
	_ = foo() 
and:
	foo()

is that the former expresses that the result is *intentionally* being discarded.  The developer obviously thought about it in the first case.  In the second case, they may have though about it, or they may not have.

This doesn’t matter for write-once-and-forget-about-it code, but it does matter when a codebase is maintained by many people over the span of multiple years.

That said, I think the discussion is missing the point.  The logic for changing the default here is the premise that most non-Void-returning functions have a meaningful result value, and that most of the time, the result is to be used.  This is clearly the case for all “pure” functions (since there are no other side effect, so the result is all the matters).  The argument to make this warning on by default is that it exposes many real world bugs due to accidental omission of the code that uses  the result.

-Chris


More information about the swift-evolution mailing list