In theory, I like this idea, and I think it fits with the general direction of Swift in terms of making APIs and their usage more explicit, particularly custom and third-party ones, but I’m concerned about what would happen if system APIs that were intended to have discardable results aren’t annotated at the same time that the feature is rolled out — while the intent is laudable, if the net result was that a bunch of spurious warnings are generated, then it makes the warning system less valuable.
That said, the problem isn’t necessarily difficult to solve — it’s just that it’s important that it actually be solved at the same time the feature is rolled out. The most obvious examples are the popViewController methods on UINavigationController — it’s very common, probably more common than not, to ignore the return value of these methods, but it would be unfortunate to need to explicitly ignore the results. (I suppose a counter argument here is that a lot of people may not even realize that those methods have a return value, but even if that’s the case, I suspect the typical pattern is to ignore the return.) Assuming that most common APIs are audited (and that APIs like popViewController methods would be marked as discardable), then I think the proposal would have a positive impact. Perhaps one way to figure out the scope of the auditing would be to determine how many Apple SDK methods that return values aren’t already marked as warn_unused_result. > On Mar 16, 2016, at 3:36 PM, Chris Lattner via swift-evolution > <[email protected]> wrote: > > Hello Swift community, > > The review of “Defaulting non-Void functions so they warn on unused results” > begins now and runs through March 21, 2016. The proposal is available here: > > https://github.com/apple/swift-evolution/blob/maout > ster/proposals/0047-nonvoid-warn.md > > Reviews are an important part of the Swift evolution process. All reviews > should be sent to the swift-evolution mailing list at: > https://lists.swift.org/mailman/listinfo/swift-evolution > > or, if you would like to keep your feedback private, directly to the review > manager. When replying, please try to keep the proposal link at the top of > the message: > > What goes into a review? > > The goal of the review process is to improve the proposal under review > through constructive criticism and, eventually, determine the direction of > Swift. When writing your review, here are some questions you might want to > answer in your review: > > • What is your evaluation of the proposal? > • Is the problem being addressed significant enough to warrant a change > to Swift? > • Does this proposal fit well with the feel and direction of Swift? > • If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? > • How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? > > More information about the Swift evolution process is available at: > > https://github.com/apple/swift-evolution/blob/master/process.md > > Thank you, > > -Chris > Review Manager > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
