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

[Kevin Ballard]

On Mon, Dec 21, 2015, at 11:17 PM, Brent Royal-Gordon wrote:
> > And that brings to mind a second question: How about functions that are generic in their return type? For example, `withExtendedLifetime<T,Result>(_: T, _: T throws -> Result) rethrows -> Result`. The return type may be Void in many cases, but when it's not Void it still may not be meaningful. It's hard to know from the generic function whether the compiler should warn if the return type is unused; my inclination is to say it shouldn't warn by default, because it's rather common to execute these sorts of functions for their side-effects. Which is to say, if the function is capable of returning Void, then it should not warn without an explicit @warn_unused_result attribute (which does mean we need to keep that attribute even if that becomes the default). The rationale being that a Void return type means the function is executed for its side-effects, and so a non-Void return type may also be executed for side-effects, and functions that are executed for their side-effects shouldn't warn. 
> 
> `withExtendedLifetime()` is generic on its return type and makes sense to ignore, but `CollectionType.reduce()` is also generic on its return type and *doesn't* make sense to ignore. I think these should follow the same rules as any other function, with the obvious exception that, if the return type *does* happen to be Void, ignoring the return value is fine.

Good point. It's worth cataloging all the stdlib functions with generic return types to find out how many want to allow unused result and how many want to warn on it. That would inform the decision as to how to behave here (because either way we'd have an attribute to pick the opposite behavior).

-Kevin Ballard