[swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

Haravikk swift-evolution at haravikk.me
Mon Mar 21 16:28:04 CDT 2016

> On 21 Mar 2016, at 20:35, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> In Swift Evolution discussions, the term @discardable was mildly preferred over @discardableResult.
> Some community members requested a new attribute enabling exceptional imported functions to be properly annotated from Objective-C source.
> Dany St-Amant requested two levels of compiler response: @discardableResult(warn) for simple warnings and @discardableResult(critical) which generates an error with unused results, such as when returning allocated resources

This looks good, I think that @discardableResult() makes sense until we can get @discardable on the return type itself. I think that if warn/critical is added then there should also be a corresponding “allow” or similar (which is what the default is), i.e- @discardableResult on its own implies @discardResult(allow) to issue no warnings of any kind.

I also like the idea of being able to add this attribute to types as well as functions, allowing the default behaviour to be changed on a per-type basis, as this would be useful for types that are specifically designed with method chaining for example (where most results are discardable as standard). While the choice of default will never satisfy everyone, this would make it easy to tweak for your own needs.

Allow us to do something like the following, assuming that @discardableResult(warn) is now the default:

	class MyChainableType {
		func chainableMethod() -> Self { … }
		func anotherChainableMethod() -> Self { … }

		func getResult() -> Dictionary { … }

Of course, if we can get attributes on return types now or in future, then the function form of the attribute should be @discardable(warn) for .getResult().
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160321/04b2bf99/attachment.html>

More information about the swift-evolution mailing list