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

[Step C]

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

> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution