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

[Austin Zheng]

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.

Austin

> On Mar 2, 2016, at 12:22 AM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I can’t remember ever returning a value ‘just in case’. I whole-heartidely support the @warnunusedresult by default.
> 
>> On 02 Mar 2016, at 09:16, Dmitri Gribenko via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> On Tue, Mar 1, 2016 at 11:50 PM, Andrey Tarantsov via swift-evolution
>> <swift-evolution at swift.org> wrote:
>>> Whoa. Everyone seems to be in favor of this. Don't you guys always return
>>> something ‘just in case’, in the best traditions of C API design? I tend to
>>> have lots of discardable results and only a few where I might legitimately
>>> forget to use it.
>>> 
>>> IMO, in most cases ignoring a return value is “safe”:
>>> 
>>> a) If a method is called only for its result, forgetting to use the result
>>> won't really introduce any new bugs — if you're not using that missing
>>> result elsewhere, storing it into a variable won't help.
>>> 
>>> b) If you're calling a method for its side effect, normally the result may
>>> be discarded.
>>> 
>>> The only case where this matters is when the method establishes a long-term
>>> relationship (like a subscription) that needs to be stored to survive. That
>>> seems like a rare case.
>>> 
>>> Any other practical cases?
>> 
>> The reason for warning on ignored "safe" returned values is that the
>> code calls the method, but it ignores the result.  Presumably, the
>> developer wrote the method call for a reason -- they wanted their code
>> to do something.  Nobody needs a fancy no-op in their code.  So while
>> discarding "safe" return values does not compromise memory safety or
>> introduce races or anything bad like that, there is a very high
>> probability that the code is just wrong and does not do what the
>> developer wanted.  It does something else, in a totally "safe" way.
>> 
>> Dmitri
>> 
>> -- 
>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution