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

[Gwendal Roué]

> Le 2 mars 2016 à 18:12, Chris Lattner <clattner at apple.com> a écrit :
> 
>> 
>> 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.

On the contrary, we agree. But you’re thinking in the current state of affairs:

> 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...

> 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.

Gwendal