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

Chris Lattner clattner at apple.com
Wed Mar 2 11:45:28 CST 2016

> On Mar 2, 2016, at 9:36 AM, Gwendal Roué <gwendal.roue at gmail.com> wrote:
>> 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.
> The former only expresses that the result is *intentionally* being discarded when there is no warning ignoring the returned value.
> As soon as there is a warning ignoring the returned value, as would be the default if the discussed proposal were accepted, people will start writing `_ = …` just to *silence* the warning. Not to express intentional discard. It will be impossible to derive any intention from `_ = …`. There will always be the shadow of a doubt…

You’re right that this is possible, but I doubt it is likely.  If I wrote this and got a warning:

  sin(x)     // warning, result of call to ‘sin’ is unused

it is possible that someone would blithely slap an “_ =“ on the line to silence the warning, but it is much more likely they’d say “whoops, I forgot something”.

>> 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.
> This is true. But there are caveats also, and all people that defend the proposal make as if there were none.

You’re right, I agree there are also caveats. That said, they seem so completely minor (compared to the win of changing the behavior) that the answer seems clear here.  That said, it is all moot unless someone comes up with a formal proposal for us to discuss rigorously :-)


More information about the swift-evolution mailing list