Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0047-nonvoid-warn.md
The review of SE-0047 "Defaulting non-Void functions so they warn on unused results" ran from March 16...21, 2016. The proposal has been *accepted, with requested revision*: The core team and much of the community agree that this proposal directly aligns with the spirit of the Swift language, making it so that the compiler will warn about obvious omissions in code that may be bugs. The @discardableResult attribute provides a good way for API authors to indicate that their functions and methods produce a non-essential result, and should not produce this warning. Clients of unannotated APIs have a simple and local way to silence the warning when they are willfully ignoring the result, and this code (the “_ =“ pattern) directly expresses that they thought about it - this communicates intent to future maintainers of the codebase. While this seems like a great direction for the standard library and other pure-Swift code, its impact on imported C and Objective-C APIs is less clear. There is significant concern that the warnings will be produced in wide-spread cases, and overwhelm users with a flurry of useless warnings that only confuse the issue. As such, the core team requests that this proposal be revised to indicate that the Clang importer will automatically add the @discardableResult attribute to all non-Void imported declarations (specifically, ones that are not marked with the Clang “((warn_unused_result))” attribute). Once the basic pure-Swift implementation of this lands, we can evaluate extending these rules to imported declarations as well, but that discussion should include empirical evidence that evaluates the impact on real-world code. Thank you to Erica Sadun and Adrian Kashivskyy for driving this forward. I filed SR-1052 (https://bugs.swift.org/browse/SR-1052) to track implementation of this task. This is slightly more advanced than a typical starter bug, but is completely tractable for someone looking to get involved in the Swift compiler. -Chris Lattner Review Manager _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
