<div dir="ltr"><b>What is your evaluation of the proposal?</b><div>+1<br><b><br></b></div><div><b>Is the problem being addressed significant enough to warrant a change to Swift?</b></div><div>Yes, the current annotation is present on most non-void functions, it adds a large number of lines to files that are properly annotated.</div><div><br><b>Does this proposal fit well with the feel and direction of Swift?</b></div><div>Yes, it removes a lot of excess code, and defaults to the safer option. It&#39;s rare in my experience for Swifty code to both mutate and return.</div><div><b><br>If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</b></div><div>N/A</div><div><b><br>How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</b><br>A quick read, I followed the discussion, I read other reviews.<br><br>----<br><br>It may also be worth considering adding an ObjC attribute so that exceptional imported functions can be properly annotated.</div><div><br></div><div>Likewise, it may be worth considering deprecating @warn_unused_result rather than removing it in a migration. A linter could ensure that audited files have either @warn_unused_result or @discardableResult on every function.</div><div> </div><div>When @discardableResult becomes @discardable, the deprecation could become final, and @warn_unused_result could be removed by migration. This migration should probably only happen if all functions in the file are annotated.</div><div><br></div><div>On Fri, Mar 18, 2016 at 12:36 PM, Erica Sadun via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>&gt;<br>&gt;<br>&gt; On Mar 17, 2016, at 7:15 PM, William Shipley via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>&gt;<br>&gt; Strong +1, with some nitpicks to enclosed example:<br>&gt;<br>&gt; I disagree that NSNotificationCenter’s returned token should be ignored without warning—this goes against the patterns I’ve seen in programming Cocoa the last 27 years, where needing to unregistering for notifications when an object is unloaded is more common than registering once and leaving it for the lifetime of the app.<br>&gt;<br>&gt;<br>&gt; NSObservervationCenter example: should not be marked. Most observer lifetimes will be shorter than the application&#39;s lifetime and view controllers should clean up after themselves when dismissed, hidden, or otherwise put away. The compiler should emit warnings about this use that the developer must override.<br>&gt;<br>&gt;<br>&gt; Are you sure we are disagreeing?<br>&gt;<br>&gt; -- E<br>&gt;<br>&gt;<br>&gt; _______________________________________________<br>&gt; swift-evolution mailing list<br>&gt; <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>&gt;<br></div></div>