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

Erica Sadun erica at ericasadun.com
Thu Mar 17 11:19:59 CDT 2016

Addressing a few common themes:

Imported code from other languages should not be warn unused. That is not the assumption the code was developed under, and Swift should not be held to that contract.
Imported code from Cocoa should not be warn unused because a full audit is impractical. 

 It seems to me that if you create a UIView(frame: rect) for example and discard the result, that is typically more error-y than intentional. On the other hand, many Boolean results and oserr results are reasonably ignorable. As for the popViewController methods on UINavigationController, whose results are typically ignored, I'm wavering between "yes, that should raise a warning" and "yes, that method should be audited and marked as disposable".

This is one of those areas where I would prefer advice and feedback from the Core Team before modifying the proposal.

This will confuse people who do not read release notes or the documentation, and they will use the less advantageous "let _ =" instead.
"This doesn't mesh with my personal coding style"
"I'm already a careful developer and my code would not benefit"
All my code has been thoroughly pre-audited and the transition will be painful.

If adopted, this proposal will incur negative costs for some developers. I believe the benefits for the language and the wider community outweigh the negatives.

This isn't fluent interface-friendly

This one confuses me as I was under the impression that method chaining consumes each result in turn, so won't cause warnings.

There isn't an "Impact on existing code" section.

Adrian and I need to add that. At a minimum:

- The migrator should remove existing @warn_unused_results in Swift code
- The section should state how code imported from other languages (particularly C-based and Cocoa) will be treated. I want advice from the Core Team on how they think this will be best addressed before I add that to the proposal.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160317/cb803895/attachment.html>

More information about the swift-evolution mailing list