> 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. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
