disc.md

Migration and Impact On Existing Code

Flipping Swift's default behavior to automatically warn on unused results should expose overlooked errors in existing code. Community review has convinced us that simply removing the existing attributes from Swift code will not be the best solution for all developers.

• For many developers, removing @warn_unused_result could be sufficient, enabling warnings to drive code audits. Deprecating @warn_unused_result instead of remove-on-migration, would better allow inspection of any code that is not @warn_unused_result.

• Some developers have requested an on-demand inversion (marking un-marked functions) for code they believe is well audited and will resist any issues with masking inherent problems. Brent Royal-Gordan wrote, "If you have done a reasonably thorough audit, deleting the annotations instead of inverting them is a destructive change. When Swift 2 changed the documentation format, the migrator didn't delete all the old doc comments. Deleting @warn_unused_result in audited codebases is akin to that."

• Concerns were raised over imported functions written in discardable-by-default environments, especially for C-language sources where community members felt imported functions should match the default behavior of the C-language. Global functions that return scalar values from Objective-C sources might be treated in the same way. We believe any Objective-C method or function that returns an NSObject should warn on ignored result unless explicitly marked. removeLast() and other pop()-like functions are examples of functions that will most probably be marked with @discartableResult attribute.

Non-migration concerns:

• 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.
• Haravikk requested that the attribute annotate types as well as functions. This would allow "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."
• 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.