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