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

[David Hart]

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